The DAV Property/Message Object Model

The purpose of this post is to clarify some issues regarding the DAV
Property/Message Object model.

DAV message bodies and properties both share the same object model.

That object model is NOT XML.

Rather, XML is one of many possible transport formats for that object model.

The message body/property object model is a tree. The root node MUST be an
element. An element is a container which MUST have a URI for a name. An
element MAY have an unlimited number of children. An element with an
unrecognized name MUST be treated as if it and its children are not present
in the tree unless the element's parent's definition instructs otherwise. A
particular element's definition MAY require that signifigance be given to
the ordering of the children. When an element is being transported, unless
the transport has special knowledge of that element's definition, it MUST
NOT change the order the children. An element may have one of two types of
children, a byte stream or an element. In the absence of further information
a byte stream MUST be interpreted as a Unicode string. Byte streams MUST be
leaves in the tree.

That's it.

So when people ask questions like "Does a server have to return, byte for
byte, the value that was submitted for a property" the answer is very
clearly NO. All the server is required to do is to return the same object
model. Even the requirement to return the same object model is abrogated in
the case of live properties (which I address in a seperate post).

So please don't get hung up on XML. It is just a transport format. We needed
to require at least one for the sake of interoperability and XML fit the
bill. I'm sure other formats will be defined in the future which may have
nice properties for certain implementations. What we liked about XML was
that it was a pretty good "One size fits all" type solution and thus seemed
appropriate as the "you must at least support this" interoperability

	I hope that helps to clarify matters,


Received on Wednesday, 22 July 1998 14:51:24 UTC