- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 7 Jul 1997 18:06:52 -0700
- 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.
Yaron
A Data Model and Operations for DAV Properties
7/7/97
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
http://somewhere.com/resource.
To create a reference to the author one would perform the following
steps.
1. Add the DAV parameter to the base URI,
http://somewhere.com/resource;DAV.
2. Add "/" to refer to the root of the resource's property namespace,
http://somewhere.com/resource;DAV/.
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.
http://somewhere.com/resource;DAV/(http:!!www.w3.org!standards!z39.50!au
thor).
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
recorded.
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
<XML>
<Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
<D:Prop>
<Propname>Source</>
<Propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/dav/</><AS>D</>
</>
<Namespace>
<Ref>http://www.foocorp.com/Project/</><AS>F</>
</>
<D:Link>
<F:ProjectFiles>Source</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/main.c</>
</>
<D:Link>
<F:ProjectFiles>Library</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/main.lib</>
</>
<D:Link>
<F:ProjectFiles>Makefile</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/makefile</>
</> </> </> </> </>
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
6.1 DELETE
The delete method, when used on a property, causes the property to be
removed.
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
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
<XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
<D:prop>
<propname>Z:Authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/</>
<AS>Z</>
</>
<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
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
<XML:Namespace><Ref>Dublin</><AS>Du</></>
<D:prop>
<propname>Du:Producer</>
<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
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
<XML:Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
<XML:Namespace><Ref>Dublin</><AS>Du</></>
<D:prop>
<propname>Z:Authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/</>
<AS>Z</>
</>
<Z:Author>Jane Doe</>
<Z:Author>Joe Doe</>
<Z:Author>Lots o'Doe</>
</> </> </>
<D:prop>
<propname>Du:Producer</>
<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
multivalued.
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
element.
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
element.
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
PROPPATCH bar;DAV/ HTTP/1.1
Host: www.foo.com
Content-Type: application/XML
Content-Length: xxxx
<XML>
<Namespace><Ref>http://www.ietf.org/standards/dav/</><AS>D</></>
<Namespace><Ref>http://www.w3.com/standards/z39.50/</><AS>Z</></>
<D:PropertyUpdate>
<Create><prop>
<propname>Z:authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/dav/proppatch/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/</>
<AS>Z</>
</>
<Z:Author>Jim Whitehead</>
<Z:Author>Roy Fielding</>
</>
</> </>
<Remove><propname>Z:Copyright-Onwer</></>
</> </>
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 SEARCH
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.
6.5.2.1 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.
6.5.2.2 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.
6.5.2.3 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.
6.5.2.4 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
6.5.2.5 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
6.5.2.6 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
stream
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.
6.5.3.1 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
<XML>
<XML:Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<AS>S</>
</>
<S:limited-search><OR><AND><Name>*</></></></>
</>
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxxx
<XML>
<XML:Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<As>S</>
</>
<XML:Namespace>
<Ref>http://www.foo.bar/boxschema</>
<AS>R</>
</>
<S:SearchResult>
<Prop>
<PropName>R:bigbox</>
<PropValue>
<XML:XML>
<BoxType>Box type A</>
</> </> </>
<Prop>
<PropName>R:author</>
<PropValue>
<XML:XML>
<Name>J.J.
Dingleheimerschmidt</>
</> </> </> </> </>
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.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.
[Bray, 1997] T. Bray, C. M. Sperberg-McQueen, "Extensible Markup
Language (XML): Part I. Syntax", WD-xml-lang.html,
http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.
[Connolly, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP - an
Extension Mechanism for HTTP", Internet draft, work-in-progress.
draft-ietf-http-pep-03.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-03.txt.
[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.
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
Operations." Unpublished manuscript.
http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html
[Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
"OCLC/NCSA Metadata Workshop Report."
http://purl.oclc.org/metadata/dublin_core_report.
[Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646", Internet Draft, work-in-progress,
draft-yergeau-utf8-rev-00.txt,
http://www.internic.net/internet-drafts/draft-yergeau-utf8-rev-00.txt.
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
ignored.
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.
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,
<XML>
<XML:Namespace><Ref>http://blah;DAV/</><AS>B</></>
<XML:Namespace><Ref>B:(B:)/</><AS>C</></>
<C:Moo></>
</>
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