[
Lists Home |
Date Index |
Thread Index
]
And is the problem with address-based unification. If the
namespace string is *owned* or it becomes illegal to bind
any other xmlns prefix to it, (regardless of that being
bad practice which it is), it makes the landgrab for
prefixes and uris unavoidable. I don't think it a shortcoming
when a spec deliberately avoids trying to specify something
the provenancing organization cannot control.
Lots of stupid things are legal. Lots of not so stupid
things aren't. We can't tell where the boundaries of
the application and the system are. If we think we can
legislate that, the W3C loses the imprimatur. No Exit.
On this one, the spec is right.
len
-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
Sent: Monday, January 28, 2002 2:55 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] xmlns:xml = "???"
At 08:35 PM 28/01/02 +0000, Michael Kay wrote:
>(1) Is it legal to specify
> xmlns:xml="http://www.w3.org/XML/1998/namespace";?
>
>(2) Is it legal to specify
> xmlns:xml="anything else"?
Both of those are perfectly legal XML 1.0. The namespaces
spec says nothing about these aside from the "by definition"
phrase that you quote. The other question you don't ask is
whether it's legal to bind some other prefix to the
http://www.w3.org/XML/1998/namespace namespace.
So this is a shortcoming in the rec. I think we can all
agree though that doing any of these things would be really
bad practice.
>Supplementary questions:
>
>(3) Do xml:space and xml:lang have any defined meaning if
>xmlns:xml="anything else" is specified?
Probably they do, since XML 1.0 binds them to the prefix "xml:".
And probably if that namespace name were bound to some other
prefix, then "otherprefix:lang" wouldn't work. But once again,
this would be really really stupid, and if any software raised
an error and threw it out on grounds of gross stupidity, I
think that would be within the spirit of the spec.
>(4) Is it legal to specify
> xmlns:xmlns="anything"?
>(and if not, where does it say so?)
Almost the same answer as for (1) and (2), but I could probably
make a stronger case that this is forbidden by the namespace
rec's assertion that this prefix "is not bound to any namespace
name". -Tim
|
