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

RE: Section 23.4 Appendix 4 - XML Namespace in WebDAV

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 2 Apr 1999 10:57:22 -0800
To: WEBDAV WG <w3c-dist-auth@w3.org>
Message-ID: <000501be7d3a$a3b3d740$d115c380@ics.uci.edu>
Caught by the spam filter.

-----Original Message-----
From: marjorie@us.ibm.com [mailto:marjorie@us.ibm.com] 
Sent: Thursday, April 01, 1999 5:42 PM
To: ejw@ics.uci.edu
Cc: gstein@lyra.org; w3c-dist-auth@w3.org
Subject: [Moderator Action] RE: Section 23.4 Appendix 4 - XML Namespace
in WebDAV

Its also important to not put semantics in prefixes as they can be changed
and still refer to the same namespace. The ordered-pair approach does not
treat the prefix like an alias for the namespace although that's all you
can safely do with it. The XML namespace spec was reluctant to apply
semantics to namespace, so they don't define what concatenation and alias
substitution mean. However, they do expect applications that use namespaces
to define the meaning, and WebDAV did. I might add that in practice, this
seems to have turned out to be a good and sensible decision.

Jim Whitehead <ejw@ics.uci.edu> on 04/01/99 07:19:39 PM

Please respond to ejw@ics.uci.edu

To:   gstein@lyra.org, WEBDAV WG <w3c-dist-auth@w3.org>
cc:    (bcc: Jim Amsden/Raleigh/IBM)

Subject:  RE: Section 23.4 Appendix 4 - XML Namespace in WebDAV

> This is really gross. The XML Namespaces spec seems to consider a
> (namespace, name) pair as the unique value, rather than namespace+name.
> Maybe I misread the XML spec.

Don't hold anything back, tell me what you *really* think about it :-)

> Doing it this way just doesn't seem Right. Why can't the DAV spec use
> the ordered-pair approach? The two links that were posted at the start
> of the thread only deal with the fact that the XML spec was included
> into the DAV spec, rather than a discussion of *why* we use this
> approach. Does anybody have a reference to a discussion on "why"? (or
> can explain why?)

One rationale is that the design group identified that this was a problem
earlier versions of the XML Namespace specification, and developed a
mechanism for addressing the problem which worked, and would ensure
interoperability across the wire. There was a perception that this wasn't a
major problem, and that it was better to rapidly develop a mechanism that
worked, than to spend a lot of time on it.

Another rationale is that we wanted to stay true to the property model
a property is a name, value pair, where the name is a URI, and the value is
a well-formed chunk of XML.  Viewing an XML namespace + element as a
namespace, element pair is different from saying they are concatenated, and
hence capable of forming a URI.  Since we wanted to marshall property names
using a namespace + element pair, the concatenation approach better
supported this marshalling.

- Jim
Received on Friday, 2 April 1999 14:05:01 UTC

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