SAX2 Namespace Support

[David Megginson]

David Brownell <david-b at pacbell.net> writes:

> I once did a pretty quick'n'dirty one that cost barely 10% even though
> it used DOM data structures (which, for attribute lists and values, are
> often grossly inefficient).  I've every reason to believe it could be
> done with much lower cost.  Perhaps your 25% was doing more work than
> was required.

Basically, an NS layer has to look at every element and attribute name
and check whether it begins with xmlns or contains a colon, and it has 
to copy (or wrap) the attribute list if it contains an xmlns*
attribute or a prefixed attribute name.  

After my initial tests, I managed some savings by maintaining a stack
of hash maps (one for each Namespace state) to cache names that had
already been seen and save some of the more expensive string
operations, but the attribute-list iteration and copying couldn't be
avoided, and they can be costly.

> Then there's also the approach of having the processing be integrated
> with the next layer, which already needs to iterate and examine.  (And
> with different goals than a parser!)  Such approaches can reduce the
> cost much further -- effectively, to zero.

Yes, but you lose a *lot* of reusability -- the Namespace processor
has to be written again for each process that uses it (XSL, XLink,
RDF, etc.) rather than just once.

> Raising that point about compatibility.  There's not been much of
> discussion abou the fairly substantial change you're proposing,
> that SAX1 and SAX2 seemingly be incompatible at this basic level.
> It's only come out implicitly in reaction to other points.

Actually, I described it quite explicitly in my posting "SAX2:
Namespace Proposal":

  With SAX2 alpha 1, the idea was to preserve SAX 1.0 pretty much intact 
  and add extra features to it.  Upon reflection, I think that it will
  make more sense to create a whole new package, org.xml.sax2 (if OASIS
  gives permission), which is similar to org.xml.sax in many but not all 
  respects -- that will avoid nightmarish problems with classpaths,
  etc., and it will be quite easy to write adapters.

For some reason, this message is missing from the archive, though
there are dozens of replies to it.

> I've been leaning in various cases to "XML+namespaces" as a default,
> but think it _must_ be possible to do more than "try" to disable it.
> Namespaces are not mandatory (not part of the XML spec) and by now
> it's well known they're not trouble-free.  SAX2 shouldn't preclude
> systems that choose not to use namespaces.

To be fair, it wouldn't preclude systems that choose not to use
Namespaces, unless they also chose to use names with colons in
different ways (and the XML 1.0 REC warns strongly against doing so).


All the best,


David

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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)