Re: Are *relative* URIs as namespace nemes considered harmful?

>  There may be and often
> are multiple resources (file://, ftp://localhost,
> ftp://canonical.host.domain)
> sharing the same entity body.

Yes of course that is clear. That the same physical file can have many
such URI


>   It depends on how the file is fetched by whoever is doing the
>   interpretation.


but what you are saying is that given my example it is impossible to
write a stylesheet for that document that uses an absolute URI for the
namespace in the stylesheet match pattern because

saxon file.xml sheet.xsl
xt  file.xml sheet.xsl
xalan  file.xml sheet.xsl
etc

all have to have some way of converting file.xml into a URL and they all
may potentially do something different.

Of course I could just use the same relative URI for the namespace in
sheet.xsl and hope that the system gives sheet.xsl a similar enough
base URI that the relative namespace URI "abc" is resolved to the same
absolute URI in both cases, but I don't really see how that is
an improvement over the current position (implied by namespace rec, but
not by xpath) that given my file

<xxx xmlns="abc"/>

I can write a template
<xsl:template match="x:xxx"  xmlns:x="abc">....
and know that the template will match the element xxx in the namespace
with name "abc" without having to second guess what namespace each
system will use, due to different base URI algorithms.

I'd like to stress that I am not arguing that relative URI namesapces
are that good an idea, but seeing as the literal and absolute approaches
come to the same thing for absolute URI, I am struggling to find any
scenario in which the "absolute" approach gives any desirable or easily
documentable behaviour when used with relative URI.

With the "literal" approach relative namespace URI work in the same way as
absolute URI, the only bad effect is that the resulting name doesn't
claim to be (and isn't) globally unique, but just unique within the
scope of the relative reference eg on the same machine.  This is
obviously bad if the namespace is defining something like MathMl or
XHTML, but if it's just a namespace containing a few variables in a one
off XSL stylesheet, I don't think this really matters too much.
(Perhaps it does, this is where my understanding of the argument
falters)

With the absolute approach, relative URI are technically still
syntactically valid but make the document essentially unusable.
perhaps that is really the intention, that it is the "forbid"
option recast in a way that does not retrospectively make
existing documents non conforming. With this approach
you can not style the document with XSL, or query into it
or process it in any way until the base URI is known, and the base URI
changes every time you move the document, or even, as shown above, you
just change from one XSL processor to another.

David

Received on Wednesday, 17 May 2000 18:43:46 UTC