W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001


From: Julian F. Reschke <julian.reschke@greenbytes.de>
Date: Sat, 14 Apr 2001 12:24:00 +0200
To: <w3c-dist-auth@w3c.org>
Message-ID: <AFEIKENBELCNEGJFCENGCEICDCAA.julian.reschke@greenbytes.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden
> Sent: Saturday, April 14, 2001 12:21 AM
> To: w3c-dist-auth@w3c.org
> Subject: Re: Issue: PROP_ATTR
> I agree with Greg. One clarification. The property name may need a
> namespace too. In this case, the usual XML rules should apply. Define a
> namespace for the name. WebDAV specifies what this means: replace the
> namespace prefix with it namespace value and concatenate it to
> the front of

Which contradicts the namespace spec and as far as I understand will be
removed from the RFC. Namespace name and local name NEVER should be
concatenated (that is, without well-defined delimiters), they are a pair,
that's it (see issue "XML_NS").

> the property name to create the key. This rule however DOES NOT APPLY to
> the value. It is up to the application to determine how to handle the
> namespace and prefix for the value. If the value doesn't specify a
> different namespace, again the usual XML rules apply and the property name
> namespace is also applied to element tags in the value, if they use the
> prefix. If this is not what is desired, the clients can put a different
> namespace on the value.

What you say is that namespaces within the contents of a property should
behave as defined in the XML namespaces recommendation, right?

> The only issues is what does the server store for the property key? The
> name after prefix substitution? The namespace and prefix so they can be
> reconstructed on a PROPFIND? I think the server needs to store all
> namespace information on the property name because WebDAV says propery
> names are XML tags.
> On storing the property name (key) with the value: if its in the value,
> store it with the value. If not, don't.

That's an implementation issue, not a specification issue, correct?
Received on Saturday, 14 April 2001 06:24:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC