W3C home > Mailing lists > Public > xml-uri@w3.org > July 2000

Re: [XML-URI] HTTP extensions framework comparison

From: David Carlisle <david@dcarlisle.demon.co.uk>
Date: Thu, 20 Jul 2000 23:23:40 +0100 (BST)
Message-Id: <m13FOjE-000OdCC@dcarlisle.demon.co.uk>
To: frystyk@microsoft.com
CC: xml-uri@w3.org


> Nope, there is nothing specific to HTTP URIs in this. As I have mentioned
> before, it just so happens that HTTP URIs use all aspects of the URI
> syntax defined by RFC 2396 and so there is a 1:1 mapping between the
> equality rules defined for HTTP URIs and URIs and RFC 2396. It is more for
> historic reasons that anything else that those rules are explained in the
> HTTP spec and not in the URI spec.

You did claim this before, and at the time this interpretation of the
URI spec was contradicted by Larry Masinter:

At 10:41 PM -0700 6/20/00, Larry Masinter wrote:
>>  There is nothing HTTP specific in the description of how to compare URIs -
>>  it just happens that HTTP URIs "use" all features of the URI spec. This is
>>  why the section is called "URI Comparison". The rules are general for any
>>  URI.
>The description of URL comparison in the HTTP document was only for the
>purpose of describing the equivalence of URLs used in the HTTP protocol.
>It certainly wasn't intended to have greater scope of applicability and
>shouldn't be taken out of context as some evidence about how namespace
>names should be compared.
>To support this, I point to RFC 2557 which also passed IETF review as
>Proposed Standard, which uses byte-for-byte equivalence after absolutization
>(and not HTTP equivalence) to determine URI equality for deciding whether
>a multipart/related body part 'matches' an embedded URL.
>If the HTTP equivalence rules were supposed to be applied outside of
>HTTP, then RFC 2557 would have to be revised. They're not, and it shouldn't.

In conversations off the list about that with Larry it is clear that he
agrees with you that creators of documents using namespaces must
obey the scheme specific restrictions ie it should be an error to
generate a document in http://WWW.W3.ORG/1999/XSL/Transform namespace
with the intention of it being a different vocabulary than XSLT
but that it is perfectly OK for XSLT to mandate (as it does) that
documents use exactly the XSLT namespace name not a variant of it
differing by case. This is an extra restriction over the current
namespace spec (and over the proposal recently voted on in
xml-plenary) however it seems a perfectly sensible suggestion. 

I believe I've argued on this list that I should be able to use the
~2^30 namespace names created by changing the cases of the letters in
the URI of my home page. However I don't really want to do that, or
even be allowed to do that. What I really wanted is that a namespace
processor should never have to decide that any of those names are
equivalent. However it does seem possible to simultaneously mandate
that receivers of documents must do literal comparison of
namespace names (talking about absolute uri here, leave issues of
relative uri for another day), but that creators of documents should
use namespace names that conform to the scheme specific rules.

However you seem to want something else, and allow receivers of
documents to interpret namespace names after applying normalisations.
As several people have commented, this would lead to severe
interoperability problems. Of course one has to be careful about
wording of what you can't do: A system could of course take a document
with some erroneous namespace name and transform it, changing the
namespace names, before passing it to XSLT (or whatever it is)
However that is transforming the document to another document before
processing it. The namespace parser can't modify the namespace names
while checking the unique attribute rules, and an xpath system can't
do case insensitive matches on the document it receives.

Received on Thursday, 20 July 2000 18:16:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:44 UTC