Skip to main content

4. Data Model for Resource Properties

4. Data Model for Resource Properties​

4.1 The Resource Property Model​

Properties are pieces of data that describe the state of a resource. Properties are data about data.

Properties are used in distributed authoring environments to provide for efficient discovery and management of resources. For example, a 'subject' property might allow for the indexing of all resources by their subject, and an 'author' property might allow for the discovery of what authors have written which documents.

The DAV property model consists of name/value pairs. The name of a property identifies the property's syntax and semantics, and provides an address by which to refer to its syntax and semantics.

There are two categories of properties: "live" and "dead". A live property has its syntax and semantics enforced by the server. Live properties include cases where a) the value of a property is protected and maintained by the server, and b) the value of the property is maintained by the client, but the server performs syntax checking on submitted values. All instances of a given live property MUST comply with the definition associated with that property name. A dead property has its syntax and semantics enforced by the client; the server merely records the value of the property verbatim.

4.2 Properties and HTTP Headers​

Properties already exist, in a limited sense, in HTTP message headers. However, in distributed authoring environments, a relatively large number of properties are needed to describe the state of a resource, and setting/returning them all through HTTP headers is inefficient. Thus, a mechanism is needed that allows a principal to identify a set of properties in which the principal is interested and to set or retrieve just those properties.

4.3 Property Values​

The value of a property is always a (well-formed) XML fragment.

XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self-describing nature allows any property's value to be extended by adding elements. Clients will not break when they encounter extensions because they will still have the data specified in the original schema and MUST ignore elements they do not understand.

XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. Note that xml:lang scope is recursive, so an xml:lang attribute on any element containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has one value, in one language (or language MAY be left undefined); a property does not have multiple values in different languages or a single value in multiple languages.

A property is always represented with an XML element consisting of the property name, called the "property name element". The simplest example is an empty property, which is different from a property that does not exist:

<R:title xmlns:R="http://www.example.com/ns/"></R:title>

The value of the property appears inside the property name element. The value may be any kind of well-formed XML content, including both text-only and mixed content. Servers MUST preserve the following XML Information Items (using the terminology from [REC-XML-INFOSET]) in storage and transmission of dead properties:

For the property name Element Information Item itself:

  • [namespace name]
  • [local name]
  • [attributes] named "xml:lang" or any such attribute in scope
  • [children] of type element or character

On all Element Information Items in the property value:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] of type element or character

On Attribute Information Items in the property value:

  • [namespace name]
  • [local name]
  • [normalized value]

On Character Information Items in the property value:

  • [character code]

Since prefixes are used in some XML vocabularies (XPath and XML Schema, for example), servers SHOULD preserve, for any Information Item in the value:

  • [prefix]

XML Infoset attributes not listed above MAY be preserved by the server, but clients MUST NOT rely on them being preserved. The above rules would also apply by default to live properties, unless defined otherwise.

Servers MUST ignore the XML attribute xml:space if present and never use it to change whitespace handling. Whitespace in property values is significant.

4.3.1 Example - Property with Mixed Content​

Consider a dead property 'author' created by the client as follows:

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe</x:name>
    <!-- Jane's contact info -->
    <x:uri type='email'
           added='2005-11-26'>mailto:[email protected]</x:uri>
    <x:uri type='web'
           added='2005-11-27'>http://www.example.com</x:uri>
    <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of <![CDATA[<RFC2518>]]>.
    </x:notes>
  </x:author>
</D:prop>

When this property is requested, a server might return:

<D:prop xmlns:D='DAV:'><author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    <x:name>Jane Doe</x:name>
    <x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]</x:uri>
    <x:uri   added="2005-11-27" type="web"
      >http://www.example.com</x:uri>
    <x:notes>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    </x:notes>
  </author>
</D:prop>

Note in this example:

  • The [prefix] for the property name itself was not preserved, being non-significant, whereas all other [prefix] values have been preserved,
  • attribute values have been rewritten with double quotes instead of single quotes (quoting style is not significant), and attribute order has not been preserved,
  • the xml:lang attribute has been returned on the property name element itself (it was in scope when the property was set, but the exact position in the response is not considered significant as long as it is in scope),
  • whitespace between tags has been preserved everywhere (whitespace between attributes not so),
  • CDATA encapsulation was replaced with character escaping (the reverse would also be legal),
  • the comment item was stripped (as would have been a processing instruction item).

Implementation note: there are cases such as editing scenarios where clients may require that XML content is preserved character by character (such as attribute ordering or quoting style). In this case, clients should consider using a text-only property value by escaping all characters that have a special meaning in XML parsing.

4.4 Property Names​

A property name is a universally unique identifier that is associated with a schema that provides information about the syntax and semantics of the property.

Because a property's name is universally unique, clients can depend upon consistent behavior for a particular property across multiple resources, on the same and across different servers, so long as that property is "live" on the resources in question, and the implementation of the live property is faithful to its definition.

The XML namespace mechanism, which is based on URIs ([RFC3986]), is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control.

The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. Thus, if a property A and a property A/B exist on a resource, there is no recognition of any relationship between the two properties. It is expected that a separate specification will eventually be produced that will address issues relating to hierarchical properties.

Finally, it is not possible to define the same property twice on a single resource, as this would cause a collision in the resource's property namespace.

4.5 Source Resources and Output Resources​

Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.

Last updated on