Re: Significant W3C Confusion over Namespace Meaning and Policy

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 
trouble.

>>> 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