[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX Filters for Namespace Processing
- From: Jeff Rafter <email@example.com>
- To: "Simon St.Laurent" <firstname.lastname@example.org>
- Date: Wed, 01 Aug 2001 16:45:46 -0700
> 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
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,
XML Development and Developer Web Hosting