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

> And how often are you really going to want to do this? Generally,

Quite often.


> Generally,
> namespaces are more than just disambiguation; they're strings that
> application code matches on, and that application layer is going to drive
> what names are meaningful. 

quite, and in this case the application is the xsl stylesheet
extracting data from specific namespaces within its own text via
document('') function. 

> Also, if you don't care about the NS per se and just want to prefix your
> names -- what's the advantage of using namespaces at all? Why not replace
> your
>      <x:foo xmlns:x="x"/>
> with
>       <x-foo/>
> 

Well I realise that this is rather a lame mundane excuse compared with
philosophical arguments on the nature of identity and existence, but
if I did that there would be no way to make the program work.


In xpath you can not refer to elements that are in a namespace unless
you declare a prefix, and usually you want to have several different
namespaces for different sorts of data within the stylesheet.

So a typical case is the top level stylesheet has

<month:x>January</month:x>
<month:x>February</month:x>
...

<day:x>Sunday</day:x>
...

Now it doesn't really matter what namespaces month: and day: are bound
to but they need to be bound to namespaces that are distinct and are
not any of the other namespaces that are being used in the stylesheet.
If you already have (as I usually have)
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:h="http://www.w3.org/1999/Markup/XHTML"
  xmlns:mml="http://www.w3.org/1998/Math/MathML"
  xmlns:om="http://www.openmath.org/OpenMath"
then I find it helpful, both for myself and as an educational tool for
others to use a rather different format for these "internal" namespace
names so typically I'd go
  xmlns:month="month"
  xmlns:day="day"
  >


a typical use is something like
 <xsl:value-of
   select="document('')/*/month:x[position()=current()/@month"/>
which if I typed it right converts a numeric month attribute value in
the input to the month name in the output.


Now clearly there is no need for the namespace names to be relative.
That is _always_ the case, it absolutely never matters for any
namespace, or xslt processing what the form of the namespace is
as it is never dereferenced. If the forbid option was taken
I could just as easily stick file:// or mailto: or x-x: in front of
the URI.  

"forbid" is not at all a problem for new documents.
"forbid" is only a problem for old ones.

The fact that it is trivial to modify the stylesheet to work in the
new setup doesn't necessarily help. I can easily change my stylesheets
but it isn't authors of programs who have problems with specs changing
it is users of them. If some poor s*d tries to run an old stylesheet
they obtained from somewhere on a new updated system implementing
"forbid" it is not so clear if it will be easy for them to fix it.
Breaking existing recommendations _does_ have a cost.

> Finally, as the past month's debate has proven, using relative names does
> not communicate well with humans attempting to read your document; 

Which is ironic as the only reason it is in that form is to
communicate to humans, the machine couldn't have cared less.

> there are too darned many possible ways of interpreting this.

that's what the text of the recommendation is for, and that's why its
a bad idea to change it without good reason.

> I understand what you're trying to do;

I think not if you suggest I could replace the namespaces by elements
in the null namespace.

But I stress no one ever _needs_ the namespace name to be relative.

I do it as an educational tool to clearly distinguish namespaces that
have global import (xsl, html, mathml and openmath, above) and those
that really I don't need to claim global import for, for which I have
typically used relative URI even though I could, as you say, just have
easily used some absolute one (or an absolue one that isn't globally
unique like file://month or mailto:month or data:,month)


"forbid" _is_ a viable option if anyone could make a reasonable
estimate of how many documents would break. (Still no confirmation
whether Microsoft need these relative URI)

With "forbid" the above stylesheet stops working, until someone
changes it to conform to the new spec.

So there is a period of pain and then hopefully all documents conform
and life can go on. Things don't silently go wrong.


"make absolute" is not a viable option.
It changes the namespace used above from "month" to "undefined" or
"error" depending on circumstances. and worse, it keeps the construct
legal so that new documents are going to keep being created and be
unusable.

"literal" is of course the best option: the stylesheet works as
intended.



David

Received on Friday, 9 June 2000 13:12:10 UTC