Re: on relative URI references

> What do you mean, it isn't how it works?.

i mean that this isn't how it works:

> For the application, the namespace
> identify is the absolutized form, and for the DOM, it is literal
> comparison.

That's not layering that's just inconsistency. I am sure that you can
make any number of use cases assuming that that break.

If the literal interpretation is taken then namespace identity has to
be the literal xmlns attribute value. DOM xpath namespaces all need to
agree on that.

However while namespaces do not have as a goal dereferencing the
namespace name as a URI it is still possible for applications
built on top of the namespace aware parse do so.

However if they are retrieving resources then they are not going to
work with all namespace names (they may not use dereferencable uri
schemes, or they may use http uri pointing at a non existing resource
or they may dereference to produce some entity unconnected with the
namespace) So this higher level protocol layer will have to specify
which namespace names it can deal with. Maybe _it_ just disallows
relative URI or maybe it (like an html link) expects to retrieve
different resources using the same relative URI reference from a
different base.

me> The same happens for namespaces, but that isn't broken it's
me>just the way it works (currently).

> Not for the nemspace spec.

yes. For the namespace spec.

> The URI spec specifies that a relative URI is relative to the URI
> of the containing document.  That's what it means.

So we revoke XSLT as well?

> Sigh.... the frustrating thing is being accused

You have our sympathy:-) (Actually, you do honestly have mine, I think
you are wrong on this technical point, but I am sure that you arguing
from honest motives of trying to improve things (from your
perspective), and if in the end the wrong decision is taken and the
whole thing collapses in a heap, it will of course all be your fault,
as it's your personal recommendation, isn't it?:-)  Whereas some of us can
more easily vanish and go and argue someplace else....

> In all the cases which you can consider, clearly, it is indeed
> completely unworkable.

In all cases that are not explictly disavowed as not being a goal by
the namespace spec, a relative uri will work in exactly the same way
as an absolute one. A namepace parser (as currently defined) never
need look at the structure of the name so know if it absolute or
relative (or not a URI at all, actually) It is just a string.
_If_ you want to pick a string that no one else will pick, then
using an absolute URI of a resource you control is a handy method
to accomplish that. If in this instance you don't actually care
about uniqueness, then any string will do.

> What amazed me was that people did it.

Well I do it occasionally (using /dev/null as often as not) just
because sometimes I want to highlight that I was _not_ claiming
any global uniqueness properties. If you are just using a namespace
to structure a few variables on a one off stylesheet, sometimes
global uniqueness seems too grand an assertion.

Since I don't think I'm particularly weird I assume if I did it,
others would have done so too.

I could have used absolutely _any_ URI for these purposes.
I used relative ones because /dev/null or x (another favourite)
are easy to type and distinguish such transient namespaces from
real permanent namespaces such as the xsl or mathml ones.

If relative uri had been banned I wouldn't have done this.

If there had not been such explicit indication that a namespace
processor never tries to dereference the namespace name i wouldn't
have done it.

But as the namespace spec is written and as Tim Bray, David Megginson
and others involved in the discussions leading up to it explained
so repeatedly on xml-dev when it came out. 

   A namespace name is just a name. there is no expectation of any
   particular resource being at the URI used as the name.

So I worked from that, and I (for no particular reason) spent some
time answering several hundred (or thousand? not counted) user
enquiries about xslt, xpath etc on xsl list and other fora, based
on this interpretation.

(I did notice that xpath was inconsistent at some point, I wish I'd
screamed then, but probably lots of people wish they'ed objected to
various things earlier:-)

So if the interpretation gets changed some of my stylesheets break
(but i don't really care about that because I can fix them)
but an untold number of people (1800+ subscribed to xsl list last time
I heard) will have (retrospectively) been mislead by my answers
stressing the "namespace name is a name" view of namespaces, and
I will feel that I (and they) have been let down by the system
making a specification then not keeping to it. That's why I've wasted
so much time (on my vacation, for what it matters:-) arguing on this
list.

> David, this was the key to the earlier misunderstanding.  I think you mean
> "for documents abusing relative URI namespace names".
> Correct me if I am wrong, but we are talking about documents which use
> exactly the same string as a relative URI-reference in two documents
> in different directories in a file system (say) and expect them to mean
> the same thing.  Yes, these would be the problem cases of course.

No that isn't what I mean. Those cases (which are not abuse, just
conforming to the spec as written) would be broken, but more
importantly I mean that under the absolute interpretation then _all_
current and future documents using relative URI as namespace names
will be some new kind of unstable and unusable XML non-document whose
effective element names depend on context.

The forbid option causes problems for existing documents (we can argue
whether it is 1 or 100000 but there must be some)

The absolute option causes problems for the unbounded number of
documents to be written in the future.

An XML document should have fixed element names.

An XML document that conforms to the namespace spec should stay
conforming if the parser reads its input from standard in.

> URI referencess were treated according to the URI spec instead of the
> namespace spec, that it would be useful and valid and stable?

Having links (relative or otherwise) to resources is clearly useful
but there is no reason at all to use the namespace mechanism for that.

> (In fact, my stance at the moment is that relative URIs should be banned as

banning has the possible problem of breaking existing documents
(I'm waiting for confirmation of my claim that this includes msxml3,
I may withdraw that) But while I think that is rather a bad thing for
a standards organisation to do it is much better to do that than to
do the absolute interpretation that produces this new and completely
unwanted and unforseen type of document. That is just taking a working
spec and replacing it by one that is unworkable.

David

Received on Tuesday, 6 June 2000 14:17:59 UTC