RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespaceProcessing)

[Aaron Skonnard <aarons@develop.com>]

<snip/>

[Simon]
> Namespaces in XML provides a means of pinning down element and
attribute
> identifiers to avoid potential conflicts.  By blessing the use of
> unqualified names within namespace-qualified contexts, W3C XML Schema
> makes precise identification of those identifiers a much more complex
> task.

On the contrary, consider the following XML schema definition and sample
instance document:

<!-- schema definition -->
<s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" 
    xmlns:tns="http://example.org/foo" 
    targetNamespace="http://example.org/foo"
    elementFormDefault="qualified">
  <s:element name="bar" type="s:string"/>
  <s:complexType name="fooType">
    <s:sequence>
      <s:element name="bar" type="s:string"/>
    </s:sequence>
  </s:complexType>
  <s:element name="foo" type="tns:fooType"/>
</s:schema>

<!-- instance -->
<f:foo xmlns:f="http://example.org/foo">
  <f:bar/>   <--|
</f:foo>        |
                |
                |       
Even when everything is qualified, you still can't figure out which bar
element this is just by looking at the QName and ignoring context (is it
the global or local qualified bar element?). 

And since everyone's already used to dealing with attributes based on
context [1], I don't see why local elements complicates things further.
As an example, consider the version attribute in XSLT. When used on a
literal result element, it must be qualified. But when used on the
xsl:transform element, it must be unqualified, depending completely on
context.
 
The only thing that matters is that both sides know when local scoping
is in use - either via schema definitions or human readable specs.
Whether or not it's harder to process locals vs. qualified elements is
debatable. 

[1] http://www.w3.org/TR/REC-xml-names/#ns-breakdown

-aaron

DevelopMentor
http://staff.develop.com/aarons