W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

The DAV Property Draft

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 7 Jul 1997 18:06:52 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F48503187ACF@RED-44-MSG.dns.microsoft.com>
To: w3c-dist-auth@w3.org
Cc: "Del Jensen (E-mail)" <dcjensen@novell.com>, "Asad Faizi (E-mail)" <asad@netscape.com>, "Jim Whitehead (E-mail)" <ejw@ics.uci.edu>, "Steve Carter (E-mail)" <SRCarter@gw.novell.com>
The following is the text version of the DAV property draft as agreed
upon by the DAV authors as the last DAV author meeting.

A Data Model and Operations for DAV Properties

1 Introduction

1.1 Introduction

Properties are pieces of data that describe the state of a resource.
Properties are data about data. The term property is used within this
proposal to disambiguate the concept from the overloaded terms
"metadata" and "attribute". 

Properties are used within distributed authoring environments to provide
for efficient discovery and management of resources. For example, a
subject property allows for the indexing of all resources by their
subject and an author property allows for the discovery of what authors
have written which documents. As explored in the next section,
properties have a long history, having proven themselves essential to
the maintenance of large document repositories.

1.2 Existing Metadata Proposals

Many current proposals contain some notion of a property. These include
PICS [Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney, 1996],
Web Collections, XML [Bray, 1997], several proposals on representing
relationships within HTML, digital signature manifests (DCMF), and a
position paper on Web metadata architecture [Berners-Lee, 1997]. 

Some proposals come from a digital library perspective. These include
the Dublin Core [Weibel et al., 1995] metadata set and the Warwick
Framework [Lagoze, 1996], a container architecture for different
metadata schemas. The literature includes many examples of metadata,
including MARC [MARC, 1994], a bibliographic metadata format, RFC 1807
[Lasher, Cohen, 1995], a technical report bibliographic format employed
by the Dienst system, and the proceedings from the first IEEE Metadata
conference describe many community-specific metadata sets.

Participants of the 1996 Metadata II Workshop in Warwick, UK [Lagoze,
1996], noted that, "new metadata sets will develop as the networked
infrastructure matures" and "different communities will propose, design,
and be responsible for different types of metadata." These observations
can be corroborated by noting that many community-specific sets of
metadata already exist, and there is significant motivation for the
development of new forms of metadata as many communities increasingly
make their data available in digital form, requiring a metadata format
to assist data location and cataloging.

1.3 Properties and HTTP Headers

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

2 A Property Model for HTTP Resources

2.1 Overview

The DAV property model is based on name/value/attribute triples. The
name of a property identifies the property's syntax and semantics as
well as provides an address with which to refer to a property. The value
of a property is an octet stream. The attributes of a property are a set
of name/value pairs that are not directly addressable. Rather they are
retrieved when retrieving a property using the property's name and are
set when changing a property's value. This specification defines three
attributes, lextype, which provides syntax information regarding the
property's value, live, which indicates if the property's syntax and
semantics is enforced by the server, and readonly, which indicates that
the property's value may be retrieved but not set.

2.2 Property Namespace

2.2.1 Problem Definition

The requirement is to be able to associate a value with a property name
on a resource and to be able to directly address that value.

2.2.2 Solution Requirement

The DAV property system should work well with currently existing
property implementation as well as database systems. The most common
property system are file properties which are flat. In addition most
databases use a fixed schema mechanism which makes efficient
implementation of hierarchical properties difficult. Specifically, each
property has a random set of children so the best a relational database
can do is to provide a table with name and value where the value is a
series of indexes into other tables, each index representing a specific
value. However most RDBS do not provide for table pointers, only index
values, so the systems would have to be jury-rigged to handle table
pointers. In addition the indexing systems are optimized for a small set
of relatively large tables where as a hierarchical property system tends
towards many properties, each with different numbers and types of
children, thus potentially requiring a table for each child.

As such, for the moment, it would seem best to implement a flat property
system. File systems will be able to easily implement them and RDBS will
be able to take full advantage of their search facilities.

However it seems that the future will belong to hierarchical properties.
As such the design of the flat property system MUST be such that it will
be possible to add true hierarchical properties later without breaking
any downlevel clients. Specifically, a flat client MUST be able to speak
to a hierarchical server and a hierarchical client MUST be able to speak
to a flat server. In each case, the worst case scenario, must only be
that the request fails.

2.2.3 Property Names

A property name identifies both the syntax and semantics of the
property's value. It is critical that property names do not collide,
that is, two principals defining the same property name with two
different meanings.

The URI framework provides for a mechanism to prevent namespace
collision and for varying degrees of administrative control. Rather than
reinvent these desirable features, DAV properties make use of them by
requiring that all DAV property names MUST be URIs. 

The property namespace is flat, that is, it is not possible to string
together a series of property names in order to refer to a hierarchy of
properties. Thus it is possible to refer to a property A but not a
property A/B.

2.3 Property Attributes

The attributes of a property provide information about the property.
Note that a property contains information about a resource. An attribute
contains information about a property. These attributes consist of
name/value pairs whose value MUST be a string. Attributes are not
directly addressable, rather they are retrieved and defined in the
context of other property operations. For example, if one retrieves a
property value, the attributes will also be returned. If one sets a
property value, one may also specify the values for its attributes.

All attributes on a server MUST be live. This means that the server MUST
only record attribues who syntax and semantics the server understands
and enforces. This normally means that clients can not define new
attributes on a property. Rather, they may only make use of the
attributes supported by the server.

If a client submits an attribute when setting a property then the server
MUST NOT record the property unless it accepts the values specified for
the corresponding attributes. Thus, if a property value is submitted
with a live attribute then the server MUST NOT record the value unless
the property will be live.

2.4 Schemas

A schema is a group of property names, attributes, and XML elements. It
is often useful to indicate support for a particular schema in a request
or a response. Schema discovery is also useful for determining if a
system supports a group of properties, attributes, or XML elements. A
property does not necessarily contain sufficient information to identify
any schemas it may be a member of.

As with property names, schemas MUST use URIs as their names.

3 DAV Schema

The DAV Schema is specified as http://www.ietf.org/standards/dav/. This
schema is used to indicate support for properties and attributes that
can be defined on a resource and XML elements that can be returned in
responses. All DAV compliant servers MUST support the DAV schema.

3.1 Live Attribute

Name: http://www.ietf.org/standards/dav/live

Purpose: To indicate that the property has its syntax and semantics
enforced by the resource on which it is recorded.

Schema: http://www.ietf.org/standards/dav/

Parent: Any property

Values= "=" <"><">

Description: This attribute is used to indicate if the resource a
property is recorded on is enforcing the syntax and semantics of the
property. The absence of the Live attribute, in a response, tells the
client that the corresponding property does not have its syntax and
semantics enforced by the resource on which it is recorded. If a live
attribute is included when setting the value of a property then the
server may only set the property if the property will be live.

3.2 ReadOnly Attribute

Name: http://www.ietf.org/standards/dav/readonly

Purpose: To indicate that the property can only be retrieved, not set
through the property mechanism.

Schema: http://www.ietf.org/standards/dav/

Parent: Any property

Values= "=" <"><">

Description: This attribute is used to indicate that the property can
only be retrieved, not set through the property mechanism. This
attribute is not meant as an access control mechanism but rather to
reflect the fact that the property is not designed to have its value set
through the property mechanism. If this attribute is included when
setting the value of a property the request MUST be rejected because if
it were accepted the property would not be ReadOnly and a server MUST
NOT accept a new value for a property unless it will use the same values
for any attributes included with the property.

3.3 DAV XML Elements

3.3.1 Prop XML element

Name: http://www.ietf.org/standards/dav/prop

Purpose: To specify the name and value of a property

Schema: http://www.ietf.org/standards/dav/

Parent: Any

Values: PropName PropValue

3.3.2 PropName XML element

Name: http://www.ietf.org/standards/dav/propname

Purpose: To specify the name of a property, which MUST be a URI.

Schema: http://www.ietf.org/standards/dav/

Parent: Prop

Values: URI

3.3.3 PropValue XML element

Name: http://www.ietf.org/standards/dav/propvalue

Purpose: To specify the value of a property.

Schema: http://www.ietf.org/standards/dav/

Parent: Prop

Values: The contents of a property.

4 Property Identifiers

4.1 Problem Definition

The addition of properties to the HTTP object model result in the state
of HTTP resources containing two separate areas, the body of the
resource and the properties of the resource. A mechanism is needed to
unambiguously refer to both.	

4.2 Solution Requirement

The mechanism used for referring to the resource directly must also be
usable for referring to the resource's properties in such a manner that
even non-DAV aware clients can retrieve DAV properties.

4.3 DAV URL Parameter

To allow for the specification of property information in the context of
an http scheme URL, a switch is needed. This switch indicates that the
path segments following it specify a property location. To this end the
"DAV" param is introduced for use with http scheme URLs. The path
segment to the right of the DAV param MUST be formatted according to the
XML Link standard, described in Appendix 3.

4.4 Name Encoding

Properties on a resource are givens URIs as a name. Thus, in order to be
able to refer to a property one must be able to put the property's URI
into an HTTP URI.

For example, the author property, whos full name is
http://www.w3.org/standards/z39.50/author is defined on

To create a reference to the author one would perform the following

1. Add the DAV parameter to the base URI,

2. Add "/" to refer to the root of the resource's property namespace,

3. Change the author property's name into parameter format by changing
"/"s to "!"s and encasing the entire value in parenthesis. We must
encase the value in parenthesis in order to indicate that we have made
the "/" to "!" translation. We translate "/" to "!" in order to prevent
confusion over where segments are and to make sure that relative URIs
will continue to work.

4. The process is now complete, the URL can be used in a GET or PATCH to
retrieve or alter the value. See appendix 3 for more information.

4.5 Compatibility with legacy systems

4.5.1 Problem Definition

The HTTP parameter space is uncontrolled, thus someone may already be
using a parameter with a value of "DAV" for some end other than the one
described here. Thus a client sending a URI with a DAV param to a server
may receive an unexpected or inappropriate response.

4.5.2 Solution Requirement

A mechanism is needed to prevent namespace collisions.

4.5.3 Proposed Solution

All DAV compliant servers MUST honor the DAV param type on http URLs.
Thus if a client knows it is talking to a DAV server, it can safely send
an http URL with the DAV param.

The client may send the http URL with the DAV param extension to a
server that is not know to be DAV compliant if the client uses PEP
[Connolly, 1997] to prevent collisions. The proper PEP header is:

DAVPEP = "PEP: {{map "DAV"}{strength must}}"

Note that this header PEP header is not compliant with [Connolly, 1997]
but the author has spoken with the authors of the PEP draft and they
will be changing the format to make the example legal.

5 Link XML Element

5.1 Problem Description

A mechanism is needed to associate resources with other resources. These
associations, also known as links, consist of three values, a type
describing the nature of the association, the source of the link, and
the destination of the link. In the case of annotation, the source and
destination of a link may not be the resource upon which the link is

5.2 Solution Requirements

The association mechanism must make use of the DAV property mechanism in
order to make the existence of the associations searchable.

5.3 Link XML Element

Name: http://www.ietf.org/standards/dav/link

Purpose: The XML document which is the value of a link.

Schema: http://www.ietf.org/standards/dav/

Values= An XML document which must have a src and dst XML element. 

Description: Link is used to provide the source and one or more
destinations of the link. The type of the property provides the type of
the link. Link is a multivalued element so multiple Links may be used
together to indicate multiple links with the same type.

5.4 Src XML Element

Name: http://www.ietf.org/standards/dav/src

Purpose: To indicate the source of a link.

Schema: http://www.ietf.org/standards/dav/

Parent: http://www.ietf.org/standards/dav/link

Values= URI

5.5 Dst XML Element

Name: http://www.ietf.org/standards/dav/Dst

Purpose: To indicate one or more destinations of a link

Schema: http://www.ietf.org/standards/dav/

Parent: http://www.ietf.org/standards/dav/link

Values= URI

5.6 Example






</>	</>	</>	</>	</>

In this example the resource http://foo.bar/program has a source
property defined on it which contains three links. Each link contains
three elements, two of which, src and dst, are part of the DAV schema,
defined in this document, and one which is defined by the schema
http://www.foocorp.com/project/ (Source, Library, and Makefile). A
client which only implements the elements in the DAV spec will not know
what the foocorp elements are and will ignore them, thus seeing the
expected source and destination links. However an enhanced client may
know about the foocorp elements and thus be able to present the user
with additional information about the links.

6 Properties and Methods


The delete method, when used on a property, causes the property to be

6.2 GET

A GET on a property returns the name of the property. Accept types may
be used to specify the format of the return value but all DAV compliant
servers MUST at minimum support a return type of application/XML. If
application/XML is used as the response format then it MUST include the
http://www.ietf.org/standards/dav/ schema.

6.2.1 Example

GET bar;DAV/(http:!!www.w3.org!standards!z39.50!Authors) HTTP/1.1
Host: foo.com

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: "1234"
Last-Modified: xxxx





				<Z:Author>Jane Doe</>
				<Z:Author>Joe Doe</>
				<Z:Author>Lots o'Doe</>
</>	</>	</>	</>

GET bar;DAV/(Dublin:Producer) HTTP/1.1
Host: foo.com

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: "2345"
Last-Modified: xxxx


		<propvalue><XML:XML>Marcus Doe</></>
</>	</>

GET bar;DAV/ HTTP/1.1
Host: foo.com

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: "1234"
Last-Modified: xxxx





			<Z:Author>Jane Doe</>
			<Z:Author>Joe Doe</>
			<Z:Author>Lots o'Doe</>
	</>	</>	</>	
		<propvalue><XML:XML>Marcus Doe</></>
</>	</>

6.3 PROPPATCH Method

The PROPPATCH method specifies how to alter a property. The message body
controls the actual action taken by a PROPPATCH. All DAV compliant
servers are required to support the use of the application/XML
content-type using the http://www.ietf.org/standards/dav/proppatch/
schema in a PROPPATCH method with a request-URI that points to the
resource upon which the property is defined.

The changes in a http://www.w3.com/standards/dav/proppatch/ request MUST
be atomically executed, partial results are not allowed.

6.3.1 Request URI

The request URI of a PROPPATCH method with the
http://www.ietf.org/standards/dav/proppatch/ schema MUST point to the
resource upon which the property is defined.

6.3.2 PropertyUpdate XML element

Name: http://www.ietf.org/standards/dav/PropertyUpdate

Purpose: To contain a request to alter the properties on a resource.

Schema: http://www.ietf.org/standards/dav/

Parent: <XML>

Values= *(Create | Remove | Insert)

Description: This XML element is a container for the information
required to modify the properties on the resource. This XML element is

6.3.3 Create XML element

Name: http://www.ietf.org/standards/dav/create

Purpose: To create the DAV property specified inside the Create XML

Schema: http://www.ietf.org/standards/dav/

Parent: http://www.ietf.org/standards/dav/PropertyUpdate

Values= Prop

Description: This XML element contains a Prop as the only element. The
PropName contains the name of the property to be created or overwritten.
The PropValue XML element contains the value of the new property.

6.3.4 Remove XML element

Name: http://www.ietf.org/standards/dav/remove

Purpose: To remove the DAV property specified inside the Remove XML

Schema: http://www.ietf.org/standards/dav/

Parent: http://www.ietf.org/standards/dav/PropertyUpdate

Values= PropName

Description: Remove specifies that the property specified in PropName
should be removed. Specifying the removal of a property that does not
exist is not an error.

6.3.5 Response Codes

200 OK - The command succeeded. As there can be a mixture of PUT and
DELETEs in a body, a 201 Create seems inappropriate.

400 Bad Request - The client has provide a value whose syntax is illegal
for the property.

401 Unauthorized - The client does not have authorization to alter one
of the properties. This error also occurs if a property is inherently
read only.

403 Forbidden - The client, for reasons the server chooses not to
specify, can not alter one of the properties.

405 Conflict - The client has provided a value whose semantics are not
appropriate for the property.

413 Request Entity Too Long - If a particular property is too long to be
recorded then a composite XML error will be returned indicating the
offending property.

6.3.6 Example

Host: www.foo.com
Content-Type: application/XML
Content-Length: xxxx




					<Z:Author>Jim Whitehead</>
					<Z:Author>Roy Fielding</>
		</>	</>
</>	</>

6.4 PUT

A PUT is specified in order to control what is returned by a GET.
However a GET on a property always returns some sort of property
containment format. As such PUT can not be used if the Request-URI
refers to a property.


6.5.1 Request-URI

The request-URI of the search method is the URI of the resource. . 

The Depth header MUST NOT be used on a SEARCH method which contains a
Limited-Search XML element ("limited search").

6.5.2 Command Format

The effects of a SEARCH method are defined by the message body. This
section defines an application/xml content type using the
http://www.ietf.org/standards/dav/ schema. This method is not normally
cacheable. Limited-Search XML element

Name: http://www.ietf.org/standards/dav/limited-search

Purpose: To specify the set of matching properties

Schema: http://www.ietf.org/standards/dav/

Parent: <XML>

Values: The value is a single OR XML element. The OR element may only
contain AND XML elements, and MUST contain at least one AND element. 

Description: This property indicates a very limited search. The search
may only be on HTTP properties. OR XML element

Name: http://www.ietf.org/standards/dav/or

Purpose: To take its members, evaluate them, get a true or false result,
"or" the results together, and have that be the total result.

Schema: http://www.ietf.org/standards/dav/

Parent: Limited-Search XML element

Values: AND XML element. AND XML element

Name: http://www.ietf.org/sandards/dav/and

Purpose: To take its members, evaluate them, get a true or false result,
"and" the results together, and have that be the total result.

Schema: http://www.ietf.org/standards/dav

Parent: OR XML element

Values: Zero or one Name XML element, and zero or one Value XML element.
There MUST be at least one Name or Value XML element. Name XML element

Name: http://www.ietf.org/standards/dav/name

Purpose: To provide a pattern against which property names are to be
compared. If the name matches then the property evaluates to true,
otherwise false.

Schema: http://www.ietf.org/standards/dav/

Parent: AND XML element

Values: Match-Stream Value XML element

Name: http://www.ietf.org/standards/dav/value

Purpose: To provide a pattern against which property values are to be
compared. If the value matches then the property evaluates to true,
otherwise false.

Schema: http://www.ietf.org/standards/dav/

Parent: AND XML element

Values: Match-Stream Match-String XML element

Name: http://www.ietf.org/standards/dav/match-string

Purpose: To specify a search pattern to be matched against an octet

Schema: http://www.ietf.org/standards/dav/

Parent: Name or Value XML element

Values: ("*" | "?" | EncodedOctet)

EncodedOctet = <An EncodedOctet uses XML encoding to encode "*" and "?"
as well as "<" and ">"

Description: This entity provides a template against which anything that
can be expressed as an octet stream may be compared. "*" is a wildcard
that matches zero or more unspecified contiguous octets. "?" is a
wildcard that matches exactly one unspecified octet.

6.5.3 Response Format

The response is an application/xml message body which contains a single
SearchResult XML element whose contents are a series of XML elements
representing matching properties. SearchResult XML element

Name: http://www.ietf.org/standards/dav/searchresult

Purpose: To contain the results of a SEARCH request

Schema: http://www.ietf.org/standards/dav/

Parent: Any, usually <XML>

Values: Zero or more Prop XML elements (defined in Properties draft) 

Description: The SearchResult XML element provides the context to inform
the client that its contents are not just some XML element, but an XML
representation of the requested property.

6.5.4 Example

SEARCH  /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: application/xml


HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxxx

					<BoxType>Box type A</>
		</>	</>	</>
</>	</>	</>	</>	</>		

The result will return all properties on the container and its members.
In this case only two properties were found, one on the container and
one on one of its members, both properties are live.

7 References

[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture." Unpublished
white paper, January 1997.

[Bray, 1997] T. Bray, C. M. Sperberg-McQueen, "Extensible Markup
Language (XML): Part I. Syntax", WD-xml-lang.html,

[Connolly, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP - an
Extension Mechanism for HTTP", Internet draft, work-in-progress.

[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for Bibliographic
Records," RFC 1807. Stanford, Myricom. June, 1995.

[Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet draft
(expired), work-in-progress, January, 1996.

[MARC, 1994] Network Development and MARC Standards, Office, ed. 1994.
"USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging
Distribution Service, Library of Congress.

[Miller et.al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. Treese,
"PICS Label Distribution Label Syntax and Communication Protocols"
Version 1.1, W3C Recommendation REC-PICS-labels-961031.

[WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
Operations." Unpublished manuscript.

[Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
"OCLC/NCSA Metadata Workshop Report."

[Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646", Internet Draft, work-in-progress,

8 Appendix 1 - Content Type Application/XML

8.1 Syntax

The application/XML content type contains an XML document. Its syntax is
as defined below.

XML = XMLStart *XMLEntity Close

XMLStart = "<" "XML" ">"

XMLEntity= Open *(XMLText | XMLEntity) Close

Close = "</>" | "<""/"Entity-Name Markup">"

Open = "<" Entity-Name *Attribute ">"

Attribute = Entity-Name "=" Quoted-String

XMLText = <An Octet Stream which uses XML encoding for "<" and ">">

Entity-Name = ([As-Tag ":"] Name) | (As-Tag ":")

As-Tag = 1*Alpha

Name = (alpha | "_") *(alpha | digit | "." | "-" | "_" | other)

Other = <Other characters must be encoded>

8.2 XML element

An XML element, as defined in the BNF, is an open tag with content
followed by a close tag. In order to prevent confusion with the term
entity as used in HTTP, the term XML element will be used.

The first XML element of a XML document MUST be the <XML> XML element.
This XML element tells the parser that it is dealing with an XML
document. So long as this XML element is present the parser can be sure
that it can parse the document, even if XML has been extended. If XML is
ever altered in a manner that is not backwards compatible with this
specification then the content-type and the outer most XML element MUST
be changed.

8.3 Entity-Name

All XML element names must map to URIs. However due to historical
restrictions on what characters may appear in an XML element name, URIs
cannot be expressed in an XML element name. This issue is dealt with in
more detail in section 10.

Entity-Names without [AS] are relative URIs whose base is the enclosing
Entity-Name. If the enclosing Entity-Name is <XML> then the Entity-Name
MUST use an [AS].

8.4 Close

The close production marks the end of a XML element.

8.5 XML Encoding

In different contexts certain characters are reserved, for example "/"
can not be used in an XML element name and ">"/"<" can not be used in a
value. As such these values must be encoded as follows: 

Encoding = Decimal | Hex4

Decimal = "&" Non-Zero *("0" | Non-Zero)

Hex4 = "&u-" 4(Hex)

Non-Zero = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Hex = "0" | Non-Zero | "A" | "B" | "C" | "D" | "E" | "F"

The numbers MUST map to the UTF8 character encodings. Please note that
the "&" character must always be encoded.

8.6 Markup Modifier

The markup modifier, ("-", after the end of an XML element) instructs
the principal how to treat a XML element with an unknown name. If the
modifier is used and the XML element is not recognized then the XML
element name MUST be stripped and the XML element's contents promoted
one level in the parse tree. If the modifier is not used and the XML
element name is unknown then the XML element and its contents MUST be

8.7 XML Syntax Shorthand

The following template is recommended for efficiently providing a
description of an XML element.

Name: The name of the XML element

Purpose: A one line description of the XML element's purpose.

Schema: The schema, if any, that the XML element belongs to

Parent: XML elements that this XML element may be a child of.

Values: A description, usually a BNF, of the simple and compound values
that the XML element supports.

Description: Further information.

Example: An example of the XML element's use.

9 Appendix 2 - Parameter Syntax for Content-Type Application/XML

HTTP 1.1 provides for a mechanism to include a parameter with a content
type. In order to prevent namespace collisions the parameters for
application/XML must use the following syntax:

Parameter = #(<">URI<">  ["=" (token | Quoted-String)])

9.1	Schema Content-Type Parameter

Parameter = <"> http://www.w3.org/standards/xml/content-type/schema <">
"=" <"> #URI <">

The http://www.w3.org/standards/xml/content-type/schema/ URL is used as
a parameter to an application/xml content type. The URL indicates that
its value lists some subset of the schemas defined in NameSpace
parameters within the enclosed document. The URI can also be used in
requests to indicate schemas that should appear in the result.

An example of the use of this parameter is to include it in an
accept-type header on a request to indicate that the response should
contain the specified namespace. Thus the client is able to inform the
server of its support for a particular set of namespaces. The server is
not required to return a result with the specified namespaces.

10 Appendix 3 - URI Path Encoding

10.1 Problem Definition

A mechanism is needed to refer to specific DAV properties in a manner
that can handle simple, composite, and multivalued DAV properties.

10.2 Solution Requirement

The reference mechanism must use the standard URL syntax so it can be
used with both currently existing and future URLs. For example, the
syntax could be appended to an HTTP URL to specify a HTTP property on
that URL.

10.3 Path Component

URIPath = "/" [segment]

Segment = ("(" Abs-URI ")" | Rel-URI)[Index]*( ";" param)

Index = ["(" ["-"]*digit ")"]

Abs-URI = < An absolute or relative URI which has been URI-Path encoded

Rel-URI = < A relative URI for which URI-Encoding(Rel-URI) == Rel-URI >

URI-Path encoding consists of the following algorithm:

1. URL encode all "!" characters

2. Map all "/" characters to "!" characters

Please note that all relative URIs are relative to the URI in the path
segment preceding them. Hence the URI in the first path segment MUST be
an absolute URI.

The purpose of the encoding is to allow URLs to be used as segments
without having to use % encoding on all the "/" which produces a URL
form which is extremely difficult for humans to deal with, and which
changes the semantics of the URL.

11 Appendix 4 - XML URI

The "XML" scheme is to be registered with IANA as a reserved namespace
that will be owned by the XML group through the W3C.

The new URI is defined as:

XML = "XML" ":" XML-Path

12 Appendix 5 - XML elements

12.1 Ref XML element

Name: XML:Ref

Purpose: A XML element that indicates that its contents are a URI.

Schema: XML

Parent: Any

Value = URI

12.2 Namespace

12.2.1 Namespace XML element

Name: XML:Namespace 

Purpose: To inform the parser that a particular schema is in use and to
provide a shorthand name for referring to XML elements related to that

Schema: XML

Parent: Any

Value = (Ref [AS])

Description: This XML element contains two XML elements, Ref and AS. The
purpose of the XML element is to inform the parser that a schema,
identified by the value of the Ref XML element, is in use and, when
appropriate, to provide a shorthand name to refer XML elements derived
from that schema using the AS XML element. The AS mechanism is needed
for efficiency reasons and because a URI can not be fully specified in
an XML open tag. The Namespace XML element's scope is all siblings and
their children.

12.2.2 AS XML element

Name: XML:AS

Purpose: To provide a short name for the URI of the schema provided in
the Ref XML entity of a namespace XML entity.

Schema: XML

Parent: XML:Namespace

Value = 1*Alpha

Description: The AS XML entity is used to provide a shorthand reference
for the URI in the Ref XML entity of a Namespace XML entity. The value
contained in the AS XML entity is generated at the XML producer's
discretion, the only requirement is that all AS values MUST be unique
within the contents of the parent of the namespace element.

All XML entity open tags contain a name of the form As-Tag:Name. The
As-Tag is the value defined in an AS XML entity inside of a Namespace.
To resolve the As-Tag:Name into a properly formatted URI replace
"As-Tag:" with the URI provided in the Ref that the AS was defined with.
Also note that AS value also applies to any URIs defined in a Ref inside
of Namespace.

For example,


So B:(B:) translates to http://blah;DAV/(http:!!blah;DAV!)/ and C:Moo
translates to http://blah;DAV/(http:!!blah;DAV!)/Moo.

12.2.3 Required XML element

Name: XML:Required

Purpose: To indicate that the read MUST understand the associated
Namespace in order to successfully process the XML document.

Schema: XML

Parent: XML:Namespace

Value: None

12.2.4 The XML URI and Namespace

In order to prevent a logical loop the XML namespace is said to be
declared, with the AS value of "XML" as a consequence of the <XML>
enclosing property.
Received on Monday, 7 July 1997 21:09:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC