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

[Ronald Bourret <rpbourret@rpbourret.com>]

"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:".

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

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

-- Ron