RE: Section 23.4 Appendix 4 - XML Namespace in WebDAV

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
in
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
where
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