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

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

Ron,

> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@rpbourret.com]
> Sent: Friday, August 17, 2001 2:59 PM
> To: Fuchs, Matthew
> Cc: Xml-Dev
> Subject: Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> NamespaceProcessing)
> 
> 
> "Fuchs, Matthew" wrote:
> > 
> > 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.
> 
> Unfortunately, this is largely akin to saying that prefixes are
> significant, which goes against the namespaces spec. In other words,
> this reserves the empty prefix for local names. You could 
> just as easily
> have reserved the prefix "local:".
> 

No, not at all.  Note that I said "qualified" and "unqualified", not
"prefixed" and "unprefixed".  All it says is that whether you are qualified
or not is significant, which is very much in line with the namespace spec.

> I think the real culprit here isn't whether local element 
> type names are
> qualified or not. It's that local element types exist at all. 

This, of course, is a different issue.  But given that they are there, the
default behavior is designed to make clear to the parser which elements are
local and which are global.

> In the XML
> 1.0 specification, element type names are global to documents.
> Namespaces made them global across documents -- that is, made them
> universal. But local element types make them global only to their
> containing element, and that breaks a lot of assumptions we hold about
> element type names. Hence the controversy.
> 

Yes, which is again a different subject.  I think that some people in the
WG, when this started, wanted to think of local names as just a convenience
mechanism and the consequences of the decision were not apparent at the
time.  One of the goals of the XML Schema Formal Description is to provide
"Normalized Universal Names" (NUNs) for all schema constructs, and they give
global names to local elements and types.

> My gut tells me that the notion of local element type names 
> also breaks
> a certain amount of technology, although my head hurts when I try to
> find concrete examples.
> 
> (The closest I can come is DocumentFragments in the DOM, which allow
> Elements, but not Attributes, as children. That is, Attributes are not
> considered to be a valid document fragment in and of themselves and
> therefore can't be moved around. One explanation for this is 
> that moving
> them without their containing parent loses context, but I'm sure that
> considerations of where DocumentFragments can be used in the API also
> plays a role.)
> 

To my mind, one of the biggest failings of the current schema architecture
is that it can't support semantic cut-and-paste for local anything because
you can no longer point back to the source definition (hence NUNs).

Matthew