RE: ANN: SAX Filters for Namespace Processing

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]

<snip/>

> The problem with elements goes away if you take the view implied by
> Simon's transformations: that an unqualified child element is
> equivalent (at the application level) to one in the containing
> namespace.  You can then mix elements from different namespaces simply
> by qualifying the element or setting the "default namespace" at a
> boundary between namespaces.
> 
> This interpretation has the disadvantage of not being supported by
> various standard tools; 

It also breaks SOAP. This is probably worth pointing out since SOAP has been
cited as an example of a spec that sanctions the use of unqualified
elements. It would be a violation of SOAP to consider such elements to have
the same namespace as their parent. That is quite explicitly not the intent
of the SOAP spec, and a SAX filter that changes this would break any
compliant SOAP implementation.

I agree with those who argue that the use of unqualified elements is bad
practice. I also think the SOAP spec takes the right approach on this. SOAP
specifies an envelope that can carry other XML documents within it. Any
unqualified elements within a SOAP envelope are part of such a document, NOT
part of the SOAP envelope. If SOAP did not allow this, then SOAP could not
be used to carry XML documents that don't use namespaces. (And given that
there are still plenty of such documents out there, that would be a pretty
draconian restriction.)

All elements defined by the SOAP spec itself MUST be namespace-qualified.
(At least in 1.2. There are some unfortunate ambiguities in 1.1.)

Given this example, I'd say it is terribly dangerous to make the general
assumption that an unqualified child element is equivalent to one in the
containing namespace. You have to know the explicit intent of the author.