Re: SAX Filters for Namespace Processing

[Jeff Rafter <jeffrafter@earthlink.net>]

> For starters, I can't easily write processing in SAX that sends all
> content of a given (namespace-identified) vocabulary to appropriate
> processing.  I have to start maintaining context explicitly in my code.
> (That happens within the filters of course, but at least it's isolated
> from other processing.)

Wow, you already answered my counter-point... My only problem with this is,
"are the unqualified elements really in the namespace?".  My thinking is
no-way-- they are unqualified-- that is pretty much cut and dry with the
namespace spec.  I think maybe we need a new term here to alleviate some of
the confusion-- the unqualified elements are declared within the same schema
as namespace X (thus sending them along in SAX processing makes sense).
They are not "in" the namespace-- they are "associated with" the namespace.

I think a filter (perhaps using something like Dave Brownell's TeeConsumer)
which split events to alternate consumers based on the logic you introduce
(figuring out which namespace unqualified locals are _associated with_)
would be more widely accepted.  Instead of changing the namespace part of
the QName tuple, you would simply use your logic as a form of processing
redirection.  They would still be unqualified-- but they would be going in
the right direction.

> The SAX-routing example is one part, but it has other ramifications.
> Moving pieces of documents from place to place becomes pretty tricky
> when there are unqualified elements.  Context can disappear, and they
> unqualified parts may also pick up a namespace declaration from
> elsewhere in the destination tree if the processing isn't careful.

This is a side-effect of XML.  Ultimately cutting and pasting will always
affect unqualified elements-- nothing can really be done about it I suppose.
We can't say "don't use unqualified elements" because people do and have
done it already (though I tell people this pretty often...)-- we have to
deal with what is done-- We can say "don't cut and paste unqualified locals
if context matters to you".  I think there are examples of both-- XSLT is a
good example of when the namespace in context (xsl:) doesn't matter to an
unqualified child.  The reason for that is because the unqualified elements
within an XSL stylesheet are not "associated with" the xsl namespace.

Perhaps a different solution to this is some type of Infoset addition
exposed through SAX interfaces-- this would be a pretty major overhaul.  An
easier (hack) solution would be to simply add an attribute to the
unqualified elements

<foo:bar xmlns:foo="http://www.example.org">
  <myUnqualifiedEl/>
</foo:bar>

 becomes...

<myUnqualifiedEl xml:assocWith="http://www.example.org"/>

After being run through your filter.  "Associated with" may be the wrong
term but it drives the point home... it could be "xml:definedWith",
"xml:relatedNamespace", "xml:unqualifedLocalContext".  This would then allow
the element to be reasonably identified if moved or out of context without
changing the fundamental identity of the component.

Then inside a call to startElement one could check the namespaceURI and if
it were null / "", then they could check to see what the current
unqualifiedLocalContext was...  Of course even if this were done-- we would
have some new issues to deal with-- such as if the element were copied
somewhere else should the unqualifiedLocalContext reflect the change?

Just some thoughts,
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting