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

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 11:19:46 +0100

> From: [email-masked] [mailto:[email-masked]]On Behalf Of James
> Clark
> Sent: Wednesday, November 21, 2001 5:03 AM
> To: Jim Whitehead; [email-masked]; [email-masked]
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
> ...
>
> I don't think the issue is anything to do with whether URIs are
> hierarchical. From reading your message, the requirements appear to be as
> follows:
>
> - DAV wants to identify elements by a URI not a URI/local name pair

I think this should read: historically, in the development of WebDAV, there
was a phase where the spec assumed the existence of a mapping like this. I
don't think that RFC2518 as published does this.

> - DAV wants the generated URI for an element <D:creationdate/> to be
> dav:creationdate
>
> - DAV to generate the URI that identifies an element from the namespace
> identifier and local name
>
> You might think that these requirements imply that the namespace

I don't think that these actually *are* requirements. At least not according
to RFC2518.

> identifier
> for DAV must be "dav:", but in fact they don't, because there is no
> requirement that the method that you use to generate the URI that
> identifies an element is to concatenate the namespace identifier and the
> local name or the element.  You can solve the problem simply by choosing
> some other method of generating the URI, which allows the namespace
> identifier to be a legal URI, as required by the XML Namespaces Rec.

Is there any (published one) that works well with arbitrary namespace names
and element names?

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 09:34:15 -0800

Accidentally caught by the spam filter. I've added "[email-masked]" to the
accept2 list.

- Jim

-----Original Message-----
From: James Clark [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 8:00 PM
To: Jim Whitehead; [email-masked]; [email-masked]
Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI)
inconsistency

> * 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 Namespaces Recommendation provides a facility to name an element by
a URI/local-name pair.  It does not provide a facility to name an element
by a URI. The element

<D:creationdate xmlns:D="dav:"/>

has a name that is a pair consisting of the (non-)URI "dav:" and the local
name creationdate.  Nowhere does the XML Namespaces Recommendation say that
you will get anything interesting or useful by concatenating the URI and
the local name. The fact that "dav:creationdate" is a fine URI is
completely irrelevant from the perspective of the XML Namespaces Rec to the
issue of whether "dav:" is a legal namespace identifier.

> 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.

You might think that these requirements imply that the namespace identifier

James

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 09:34:50 -0800

Accidentally caught by the spam filer. I've added
"[email-masked]" to the accept2 list.

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 12:49 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI)
inconsistency

> IMO, a URI scheme has identity, and so should be able to be identified
> by a URI reference.

Right. Insofar as RDF is concerned, which provides for a
concatenative mapping from qname to URI, you could do the
following:

   <dav:creationdate xmlns:dav="dav:"/>

Where "dav:" is both a URI denoting the URI scheme, and an xmlns
prefix. Which is which is 100% clear in the XML syntax.

This gives the (RDF) URI "dav:creationdate" as desired and
provides for consistency between URI and qname representation.

Eh?

Though this doesn't help much in a non-RDF context where a
given qname is interpreted as just "{namespace}name" rather
than the concatenation "namespacename".

Cheers,

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [email-masked]

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 09:36:26 -0800

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 4:31 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

> > 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,

The interpretation of a URI scheme prefix as a valid
URI also makes sense from the viewpoint of RDF (at least
to me ;-) in that otherwise, one has no way to make
statements about the URI scheme itself.

The same is true for a URN Namespace.

Thus, "DAV:", "http:", "urn:", and "urn:issn:" should all
be considered valid URIs. Not necessarily valid in terms
of the individual schemes themselves, but in terms of the 
semantics assigned to those prefixes by RFC2396 and RFC2141.

I.e. "http:" is not a valid HTTP URL but it is a valid URI
denoting the HTTP URL scheme.

> I doubt that anybody is going to touch XMLNS,

No need to touch XMLNS. If the above are URIs, then you
can use them as namespace URI refs.

Patrick

--

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 09:36:26 -0800

Accidentally caught by the spam filter. I've added "[email-masked]" to the
accept2 list.

- Jim

-----Original Message-----
From: Dan Brickley [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 4:46 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

> statements about the URI scheme itself.

Not so. It is possible to describe things without knowing their URI. We
do it all the time. Here, you can describe the scheme indirectly, eg:

<rdf:RDF blah blah...>
<Scheme>
 <prefix>dav</prefix>
 <name>The DAV URI scheme</name>
 <seeAlso rdf:resource="http://www.webdav.org/"/>
 <blurb>A URI schema for ... </blurb>
</Scheme>
</rdf:RDF>

We can further tighten things by saying that the RDF property sketched
here, 'prefix', is a UniqueProperty (using DAML+OIL or another Web
ontology language). That tells us that an individual Scheme is picked out
by each value of 'prefix'.

BTW http://www.w3.org/Addressing/schemes.html is generated using a similar
technique; details at http://www.w3.org/Addressing/schemes.html#ctech

Dan

(dropping out of this cross-posted thread and all its spinoffs...)

--
mailto:[email-masked]
http://www.w3.org/People/DanBri/

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 09:36:27 -0800

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 4:57 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

> From: ext Dan Brickley [mailto:[email-masked]]
> Sent: 21 November, 2001 14:45
> To: Stickler Patrick (NRC/Tampere)
> Not so. 

I stand (somewhat) corrected.

> It is possible to describe things without knowing 
> their URI. 

Just because something is possible, does not mean it is optimal.

> We

But this opens up the question of what the canonical identity
of the URI scheme is and how equivalence operations (graph
tidying, etc.) apply to such complex structures.  A single
URI provides a single, consistent point of reference,
and one that is not bound to RDF, but is acceptable to
any web application that is "URI aware".

> by each value of 'prefix'.

But that's the whole point of a URI, no? Why introduce yet another
mechanism (and one that is less general) when a reliable and
fully unambiguous interpretation can be ascribed to URI prefixes
and URN Namespace prefixes? 

Surely the more general and economical solution would be better?

And BTW, most RDF parsers are already quite happy interpreting 
"http:" and similar URI prefixes as a URI ;-)

Patrick

--

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 14:15:48 -0800

Accidentally caught by the spam filter. I've added "[email-masked]" to the
accept2 list.

- Jim

-----Original Message-----
From: Mark Baker [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 1:56 PM
To: Martin Duerst
Cc: Jim Whitehead; [email-masked]; [email-masked]
Subject: [Moderator Action] Re: RFC2518 (WebDAV) / RFC2396 (URI)
inconsistency

> Well, it's not WebDAV's business to mess around with bases for
> namespaces. Namespaces don't currently use XML Base, and probably
> they won't in the future. There was an extensive discussion of
> whether namespace uris could be relative uris, and the conclusion
> as far as I remember was that it should be discouraged.

That decision[1] deprecated the use of relative URI for namespace names
*for W3C work*.  While certainly a cautionary note to others, I don't
see how it can prevent work done outside the W3C from using them.

 [1] http://www.w3.org/2000/09/xppa

MB
--
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
[email-masked]

---

From: "Jason Crawford" <[email-masked]>
Date: Fri, 23 Nov 2001 12:29:15 -0500

> We'd probably need to cover some more issues:
>
> - how does a server decide which NS to use in a reply if the request
didn't
> contain a body (PROPFIND for instance),
I would suggest that this not go in the spec.  It might not even be
necessary
for server to do this.  Let's just get our code bases to accept both URI's.
When
we achieve this, and our updated code becomes prevalent in the field, this
issue
will be largely moot and implementations can begin to xmit the new URI.

Perhaps if we find there are a lot of changes as we move to draft standard,
we can suggest that the draft standard include a header to denote
draft-standard
support.  But I don't think that's necessary for this issue, so let's not
tie that
in to this issue right now.

> - clarification, that <foo xmlns="DAV:"/> and <foo xmlns="newuri..." />
map
> to *identical* properties,
Maybe. It seems obvious.  If I alone were to make the choice, I'd tend to
not
even mention it.

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Sun, 25 Nov 2001 15:10:57 -0500

<<
Besides, even if we tried to "fix" RFC2518 on this issue, that's not the
only place where it crops up.  I know of other namespaces used in shipped
software products where the namespaces look like a string of characters
ending in ':'.   Changing the "DAV:" prefix won't fix those, whereas a
loosening of either the XML namespaces requirements or the URI requirements
would.
The 2396 folks seem intransient on this issue.  OTOH it doesn't sound like
we've discussed this with the namespace folks.  Perhaps you'd like to
take those other examples you have and make a proposal to the namespace
committee?  We could defer this issue a few weeks until we have an idea if
your proposal will be adopted.  I can be responsible for making sure we
bring up this topic again.

So Lisa, are you game?

---

From: "Jason Crawford" <[email-masked]>
Date: Sun, 25 Nov 2001 16:57:00 -0500

<<
The other issue is not really an issue, but rather a point that would
need to be made in the revised spec.
Re: adding text to mention that the properties are the same regardless
of the use of the new/old namespace URI....

That sounds fine to me.  I won't protest adding that.  :-)

---

From: "Jason Crawford" <[email-masked]>
Date: Sun, 25 Nov 2001 18:30:36 -0500

> The 2396 folks seem intransient on this issue.
Whoops.  I meant intransigent. :-)

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 29 Nov 2001 01:08:19 -0500

On Wed, Nov 28, 2001 at 04:15:23PM -0500, Jason Crawford wrote:
>
> Roy,
>
> > In other words, I think that "scheme:" is only a valid identifier for
the
> > namespace if the scheme defines it as such.
> > What are you suggesting here?  Where would a scheme define it as such?
> > Would this require a change to 2396 that you'd support?  Or some place
> > else?
> If two or more independent implementations are doing something with the
> protocol that is not allowed by the RFC, and rough consensus within the
> working group is that those implementations are doing no harm, then the
> protocol specification should change to accommodate them.  Whatever
change
> is made to 2396 will have to also take into account the history of
> existing implementations.
>
> That doesn't mean it will change any time soon, but we can add it to the
> list of errata, which I need to compile anyway.

Then it sounds to me like we have enough resolution of this for me to log
it
on the webdav issues list as temporarily resolved, and to note that it
should be
revisited again in a year to insure that the change in 2396 actually can be
counted on.

Any problems with this?

J.