Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX Filters for Namespace Processing
 > 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
