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

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

This has been a fascinating thread.  As one of those who'd argued most
vociferously for the current default mechanism in XML Schema, I'm going to
try to briefly explain what's happening.  Also, having been such a
vociferous proponent of one side of this issue, I'll start by saying this
was one of the most, if not the most, contentious issue(s) in the
development of XML Schema.  As a committee, we then chose the technically
brilliant strategy of giving both sides what they wanted.  As we can see,
this remarkably improved XML Schema because, in retrospect, both sides were
out to lunch.  But more on that later.  Right now, I just want to explain
the rational behind the default behavior, which Aaron seems to realize (but
I'll elaborate).

First, XML Schema allows one to mix and match any number of schemas in a
single instance.  Each one of those schemas may have associated with it a
namespace.  One of those schemas is permitted to be unqualified.  I'll say,
right off the bat, that I think this is a _really_bad_thing_to_do_.

Now, if you don't have any unqualified schemata in a document, then the
default behavior of elementFormDefault gives the following invariants:

1) all top-level elements are always qualified
2) all locally declared elements are always unqualified

From which one can derive the following hard and fast rule about locally
scoped elements:

3) All unqualified elements are locally declared in the type of the
immediately enclosing element (modulo inheritance) and therefore cannot be
confused with any other unqualified element with the same local name
declared in some other type.

This should be enough to provide Simon with exactly the information he
wants.  We are using the qualified/unqualified distinction so that
"Namespaces in XML provides a means of pinning down element and attribute
identifiers to avoid potential conflicts".  And this even without access to
the schema.

If on the other hand, one flips the behavior of elementFormDefault, then all
locally declared elements show up as qualified in the schema of definition,
but then one cannot distinguish among the various different elements in that
schema which may have the same local name.  Eg., suppose I have a schema in
the "confused" namespace with global elements foo, bar, and baz, and foo has
locally declared bar and baz elements, and bar has locally declared foo and
baz, etc.  Then if I have an instance:
 <c:foo xmlns:c="confused">
    <c:bar>
       <c:baz>
          <c:foo/>
       </c:baz>
    </c:bar>
 <c:foo>

then there are 3 declarations of c:bar in the "confused" schema, if
elementFormDefault is qualified, which might apply - one actually needs the
schema to be sure.  However if elementFormDefault is unqualified, then c:bar
can only be the global bar and one can tell that the c:bar above is the
global one and in:

 <c:foo xmlns:c="confused">
    <bar>
       <c:baz>
          <foo/>
       </c:baz>
    </bar>
 <c:foo>

the bar and the inner foo _must_ be local, while the baz and outer foo must
be global.  On the downside, however, this approach works very badly with
default namespaces, so if you're planning to always validate but like
writing instances by hand (in which case flipping the default means you can
use default namespaces), or if you need to use a schema with no namespace,
this has problems.

Which comes to why the solution arrived at by the W3C Schema WG is
problematic - the real issue is how the _instance_ author wants to use
qualification to convey information about his document.  The _schema_ author
cannot know what elements will appear in the instance, or which schemas will
be mixed.  Therefore the appropriate solution would be to get rid of
elementFormDefault and provide appropriate mechanisms in the _instance_ to
specify how this should work for the particular instance under
consideration.

Matthew

> -----Original Message-----
> From: Aaron Skonnard [mailto:aarons@develop.com]
> Sent: Tuesday, July 31, 2001 9:21 PM
> To: Xml-Dev
> Subject: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> NamespaceProcessing)
> 
> 
> <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
> 
> 
> 
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org