xml-dev - SAX2: Namespace processing features

[David Megginson <david@megginson.com>]

David Brownell writes:

 > General SAX2 Observations> 1) The feature mechanism is busted wrt the two
 > namespace-related features.
 > 
 > Agreed.  As the simplest conceptual issue, two flags define four states ...
 > one is declared illegal, and there are really only two useful models for
 > working with XML documents (XML, or NS).  Why are three  models provided?

Here's my thinking on the three models:

1. Namespace-aware processing (typical case): xmlns* attributes should
   be invisible to most apps, because they are really pure
   declarations (I would have perferred PIs, but that's ancient
   history now).  Making xmlns* attributes available to all apps would
   hoist unnecessary complexity on most of them.

2. Namespace-oblivious processing (common case for now): many apps
   still need to work at the raw XML 1.0 level rather than the
   Namespace level -- they need to see qualified names with prefixes,
   for example, and xmlns* attributes are real attributes to them.
   Making these apps reconstruct xmlns* attributes based on
   start/endPrefixMapping hoists unnecessary complexity on them.  It's 
   also necessary for a few apps to be able to specify that they don't 
   want the XMLReader even to attempt Namespace processing (because of 
   non-standard prefix use, etc.).

3. According to many posters, there exist apps that want to have it
   both ways: they want to be able to work at both the raw XML 1.0
   view and the cooked Namespaces view at the same time -- allowing
   this level as well makes things messy, but the demand is clearly
   there.

So, there has to be some way for an app to say that it does or doesn't
require namespace processing and that it does or doesn't require
qnames and xmlns* attributes.  There's no harm in providing qnames in
either case, but providing xmlns* attributes can mess up the model.

I'll admit that the two features I chose are a little awkward, but I'm
still having trouble thinking of a credible alternative.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************