W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2004

Re: qualified local/global Re: Namespace problem

From: Burak Emir <Burak.Emir@epfl.ch>
Date: Thu, 19 Aug 2004 12:47:14 +0200
Message-ID: <41248532.20605@epfl.ch>
To: xmlschema-dev@w3.org
CC: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, mhk@mhk.me.uk

C. M. Sperberg-McQueen wrote:

>On Wed, 2004-08-18 at 10:00, Burak Emir wrote:
>
>  
>
>>My confusion is all due to my belief that namespace prefixes would
>>never play a role in attribute *values*, which is obviously wrong
>>for XSDs.
>>    
>>
>
>As well as for XSLT stylesheets and XQueryX documents and any other
>documents which have XPath expressions as attribute values.  If you
>  
>
IMHO these could be fixed if either
(1) prefix declarations for use in attribute values were independent of 
namespaces in the enclosing document, or
(2) it would be possible to use URIs directly
These options are not mutually exclusive, they would in fact best be 
used together.

>>I, for one, would appreciate an XSD syntax that makes these things
>>more straightforward (=does not use xmlns attributes).
>>    
>>
>
>While I'm sympathetic to your view that having to specify both a
>namespace prefix and the targetNamespace attribute for the target
>namespace is a pain, I wonder whether all schema authors would find
>
>  <xsd:element name="fallImportExport" 
>    type="{grips://xml.recom-verlag.de/comm/plem}FallImportExport"/>
>  <xsd:element name="fall" 
>    type="{grips://xml.recom-verlag.de/comm/plem}plem:Fall"/>
>  <xsd:element name="satzArt" 
>    type="{http://www.w3.org/2001/XMLSchema}string" />
>
>preferable to 
>
>  <xsd:element name="fallImportExport" type="plem:FallImportExport"/>
>  <xsd:element name="fall" type="plem:Fall"/>
>  <xsd:element name="satzArt" type="xsd:string" />
>
>  
>
Imagine the above, shorter version together with
<xsd:declare-prefix name="plem" 
uri="grips://xml.recom-verlag.de/comm/plem"/>
<xsd:declare-prefix name="xsd" uri="http://www.w3.org/2001/XMLSchema"/>

A simple macro expansion would then lead to the long version above, 
something that every XSD implementor can easily implement.

>I hope this helps, even though the weary fact of the matter is that
>with regard to namespaces nothing ever really helps except abandoning
>the hope that they will someday make sense and feel natural, and
>learning to live with them (note that some people do find namespaces
>natural and sensible -- as far as I can tell they were born that way,
>and others were born the other way, and there is no crossing over).
>
>  
>
It sure does, I certainly have a better feeling for the problems and 
implications. Also I find namespaces as indispensable as packages or 
modules in programming languages. When using namespaces, the conventions 
of "namespace prefixes are reused in attribute values" may feel 
uncomfortable, and not scale up, but it can somehow be dealt with.

The problem I see is that these dependencies of the XSD(or stylesheet or 
XqueryX code) on the prefix-namespace mapping of the enclosing document 
*requires* an Infoset implementation that includes these 
prefix-namespace mappings. Upon parsing, one cannot just "forget" the 
xmlns attributes, every node has to store them, even though they served 
their purpose of uniquely identifying element and attribute names.

Operations like structural equality become a nightmare requiring 
canonicalization work, memory requirements can go up. And if the XML 
document was not an XSD, XSLT or XqueryX document, it is unlikely that 
this additional information is ever used.

Instead, if there is "application level prefix declaration", then 
prefixes are just part of the content, and XSD developers could in one 
extra pass acquire the information from a core Infoset (i.e. one that 
does not need to store xmlns declarations). Moreover, developers don't 
need to care for xmlns declarations. This would avoid the above 
problems, lower implementation costs and steepen learning curves.

cheers,
Burak
Received on Thursday, 19 August 2004 10:47:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:10 UTC