Re: Is a namesapce a resource? - was: duck

> I'm missing something. document('') works or doesn't work independent of
> whether _namespaces_ permit relative syntax, doesn't it?

yes, of course.

> ... Huh? If XPath and XSLT are namespace-aware, I would think that they
> would be matching on the Namespace and localname, _NOT_ on the prefix --
> which according to the namespace spec should be considered only "syntactic
> sugar". If so,

Yes quite so.
>  then it _does_ matter which namespaces these are bound to.

except in this case, the data and the stylesheet are in the same file
and are using the same namespace declaration so while it is true that
it is the namespace name that is being matched not the prefix,
if relative URI were banned with the forbid option, I could change
the one occurrence of
xmlns:day="day"
to xmlns:day="http://foo.bar/baz"
and the stylesheet would work just as well. So it is hard to argue
that the namespace matters that much. Personally I think using a
globally unique identifier for what is effectively equivalent
to the name of an array in other programming languages just looks
like making claims of grandeur that are not warranted. But I only did
this because it was clearly legal and I wanted to call my namespace
"day" I did not want to call it some variable name depending on the
context and I did not imply the existence of any file called "day"
anywhere. If either of those things had been implied by the namespace
spec I would not have done this.

> Sometimes the right thing to do is to make the change as quickly as
> possible, before the number of documents impacted by it grows.

True, but as I commented before, if an organisation decides it needs
to do that, then it also needs to be honest and say that is what it is
doing, it should not try to creatively re-interpret its texts and
imply that existing uses and users were incorrect, and that really no
change has occurred.

In this case there is also the added problem that one of the proposed
changes to "make absolute" interpretation is just so much worse than
the current solution, in that it creates XML documents whose element
names vary as the document is moved. Thus not only do you have the
short term pain of breaking an existing spec, you have the long term
pain of a new broken design.

> precisely because folks are confused by how to interpret
> the relative syntax

The namespace spec is so clear on this point it honestly never
occurred to me that anyone could possibly interpret relative
namespace names in any other way. When at some point I noticed xpath
conflicted with this, I just thought it an error (but regretably did
not complain) also the stylesheet itself would also work in this case
with the absolute interpretation as the namespace is only declared in
one place.

> I think it is viable, IF one accepts that the results are in fact unstable
> and hence highly unsuitable for most namespace-aware operations. Which some
> folks seem to consider a reasonable result. "If you use relative syntax,
> you're referring to a family of resources; which one you get depends on
> your context. If you don't like this interpretation you shouldn't have used
> relative."

That means that every application that deals with XML files has to be
able to cope with the possibility of such unstable non documents.
this appears to be a large price to pay for zero gain.

> it just breaks the same files that the "forbid" option breaks.
> The downside is that it breaks them in a far less diagnostic manner -- they
> don't generate error messgaes, they just may not work as expected.

No, it breaks more files. "forbid" conceptually breaks a finite number
of files, those files using relative names in existence at the time
the decisiion is taken (or perhaps this list will run forever and
there won't be a decision?) "make absolute" legalises a whole class of
broken documents forever. 

David

Received on Monday, 12 June 2000 19:29:55 UTC