Re: [XML-URI] HTTP extensions framework comparison

David,

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

I am very glad to hear that - this is great news!

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

Yes, and I think this is a very important step in the right direction.

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

The rules I have advocated is that a receiver MUST at least perform
octet-by-octet (ignoring relative URIs for that other day) but MAY apply
URI space equality rules if it knows about them. What I have further
advocated is that a generator of namespaces SHOULD NOT expect anything
else but octet-by-octet comparison. The reason for this is that you can
think of dealing with namespaces as a layered process:

1) Apply literal comparison (ignoring relative URIs for now)
2) Apply URI scheme context dependent equality rules
3) Perform resolution of the URI if a mechanism is known for
   how to do this
4) Interpret the response and learn how to deal with it the
   namespace in some way
5) etc.

Only level 1) is mandatory. Level 2) to 4) and beyond can fail or not be
performed at all. If, however, they are performed, they may provide the
application with information that two namespace URIs really are the same
and it is fully valid for the recipient to apply this knowledge if it can
do so.

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

Level 2) and beyond can certainly be done without changing the namespace
identifiers - I would absolutely agree with you that rewriting the
document is generally a bad idea.

Henrik

Received on Saturday, 5 August 2000 01:51:38 UTC