W3C home > Mailing lists > Public > www-tag@w3.org > February 2005

Re: Significant W3C Confusion over Namespace Meaning and Policy

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 16 Feb 2005 17:42:51 +0100
Message-ID: <4213780B.3060606@expway.fr>
To: Dare Obasanjo <dareo@microsoft.com>
Cc: www-tag@w3.org

Dare Obasanjo wrote:
>>> No, they won't. At least not if you are using MSXML or System.Xml in the
>>> .NET Framework. The same problem exists with xml:base today. In both
>>> libraries, the assumption we made was that the XML namespace would be
>>> unchanging.
>> Based on what grounds did you decide to make such a bold assumption?
> [Dare Obasanjo] That decision was made before my time but given the
> fact that this thread started because of similar discussions around
> other specifications I don't think it is as unreasonable as you claim
> to think that the number of names within a namespace will be
> unchanging.

It's one thing to believe that a rule applies in vocabulary design 
(which is what sparked this thread) and another to imagine a restriction 
to be in the specification that's simply not there when implementing an 
XML framework that is supposedly generic. It's an obvious request for 

>>> For this reason, we don't allow users to specify a schema
>>> for the XML namespace but instead always use an internal schema with a
>>> fixed list of attribute declarations {xml:lang, xml:space}.
> Is there anything in the XML Schema spec that makes this behaviour
> conformant?
> [Dare Obasanjo] Yes. Schema locations are hints not directives. A XML
> Schema validator can ignore locations and use schemas it already knows
> about.

Oh right sorry, I'd forgotten that XML Schema was thoroughly broken in 
its specifying of xs:import. Still, it seems like a strange reason to 
expect the xml:* namespace to be fixed. The whole point of reserving 
names in the spec is so that future specs can add new ones!

Robin Berjon
   Research Scientist
   Expway, http://expway.com/
Received on Wednesday, 16 February 2005 16:42:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:07 UTC