RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency

Correction: my mailer (or someone?) discarded my umlaut A. So
the example below
> <D:prop-A xmlns:D="DAV:"/> would give DAV:prop-A which is not
> a valid URI either.
should be read with two dots above A...

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Wednesday, November 21, 2001 10:46 AM
> To: Jim Whitehead; w3c-dist-auth@w3.org
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> >
> > Let me reconstruct how we got here.
> >
> > * WebDAV uses the "dav:" URI scheme for the name of XML elements used in
> > protocol messages, and for the name of properties.
>
> I try to summarize my knowledge of XML element names, so either
> Julian can correct me, or everyone knows what we are talking about:
>
> Unfortunately, the name of XML elements in XML 1.0 ist just the name
> of the element as written in the document. So, the name of the elements
> in
>   <D:creationdate xmlns:D="DAV:"/>
>   <x:creationdate xmlns:x="DAV:"/>
> is "D:creationdate" and "x:creationdate". These two _names_ are not
> equivalent for XML parsers!
>
> In namespace-aware parsers, the name does not change. However such
> parsers subdivide a name in two parts: namespace-prefix + localname.
> This gives in our example:
>     nsprefix        localname
>     D               creationdate
>     x               creationdate
> NS-aware parsers require that each namespace-prefix be defined in
>  a namespace declaration (as it is the case in the example). Note
> that the names of the elements are still unchanged and they are still
> not equivalent!
>
> Now, XML-NS does a trick and defines equivalence for a new thing
> called an expanded element type, consisting of localname and the
> belonging namespace-URI. This gives in our example:
>     localname       namespace-URI
>     creationdate    DAV:          (which is no URI, unfortunately)
>     creationdate    DAV:
> which indeed are equivalent.
>
> Coming back to WebDAV:
>
> It is misleading to say that the name of the property
> creationdate in WebDAV is DAV:creationdate. Because when you
> serialize it to <D:creationdate xmlns:D="DAV:"/> the name
> of the XML element is "D:creationdate".
>
> Another misleading thing is to assume that the localname of
> an XML element is appended to the namespace URI. As Julian pointed
> out, this is neither defined, nor always possible, since allowed
> character sets for XML element names and URIs differ. Example:
> <D:prop-A xmlns:D="DAV:"/> would give DAV:prop-A which is not
> a valid URI either.
>
> And finally as for Jim's recommendation to XML-NS: requiring XML-NS
> to accept DAV: in namespace URIs, means to give up the notion that
> the namespace is an URI. Instead the namespace-thingie would be
> an unstructured sequence of characters.
>
> //Stefan
>
> > * While the BNF for "dav:" URIs has never been explicitly defined
> > (something
> > we should do when we revise RFC 2518), if we had, its definition
> > would be as
> > follows:
> >
> > davuri = davscheme ":" davvalue
> > davscheme = "dav"
> > davvalue = opaque_part
> >
> > From RFC 2396 we know that the opaque_part is defined as:
> >
> > opaque_part   = uric_no_slash *uric
> >
> > That is, the "dav:" URI scheme can be considered a member of
> the class of
> > non-hierarchical URIs described on page 12 of RFC 2396. In
> particular, it
> > was never the intent that just the string "dav:" would be
> > considered a full
> > URI. The string "dav:" is a URI scheme name, not a URI. The
> string "dav:"
> > plus a string matching the production "opaque_part" is a URI.
> >
> > * WebDAV marshals "dav:" URIs that are the name of XML elements as a
> > {namespace} + {opaque_part} pair.  So, for example,
> "dav:creationdate" is
> > <D:creationdate xmlns:D="dav:">.
> >
> > * The XML Namespace recommendation requires that the namespace
> > identifier be
> > a URI.
> >
> > * Since "dav:" scheme URIs are members of the class of non-hierarchical
> > URIs, the only constant part is the URI scheme name itself,
> > "dav:". From the
> > definition of non-hierarchical URIs given in RFC 2396, ALL
> > non-hierarchical
> > URIs will share this quality. Since "dav:" is the only constant
> > part, it is
> > the only part of a "dav:" scheme URI suitable for use as the namespace
> > identifier.
> >
> >
> > To summarize:
> > * The "dav:" URI scheme is perfectly legal according to RFC 2396.
> > Therefore,
> > no change is needed to RFC 2396.
> > * It is only the use of the "dav:" URI scheme name as an namespace
> > identifier that is violating any specification. Either RFC 2518
> or the XML
> > Namespaces specification could be changed to rectify this.
> >
> >
> > In my opinion, it is natural to want to use the URI scheme name
> as the XML
> > namespace identifier.  That is:
> >
> > <D:getcontentlength xmlns:D="DAV:">
> >
> > is more natural than:
> >
> > <D:getcontentlength xmlns:D="http://www.webdav.org/">
> >
> > Not to mention that it uses fewer bytes on the wire (not a huge
> > consideration these days, but those bytes add up over millions of daily
> > users).
> >
> > As a result, I recommend that the XML namespace recommendation
> be modified
> > to allow the use of just the URI scheme name as a namespace identifier,
> > perhaps limited to just members of the set of non-hierarchical URIs. It
> > seems clear to me that the XML namespace recommendation was written with
> > only the class of hierarchical URIs in mind, and as a result
> it's not too
> > surprising that a glitch arose in the first use with
> > non-hierarchical URIs.
> > Based on Julian's experience, and our experience with multiple WebDAV
> > implementations, accepting a URI scheme name as a namespace
> > identifier would
> > codify existing, interoperable, practice.
> >
> > - Jim
> >
> >
> >
>
>
>
>

Received on Wednesday, 21 November 2001 04:55:43 UTC