SAX2 Namespace Support

David Megginson david at
Tue Dec 21 03:14:06 GMT 1999

Richard Anderson writes:

 > Why are you trying to complicate ours lifes :)
 > Please change these from:
 > >   public void startElement (String ns, String name,
 > >                             AttributeList atts)
 > >     throws SAXException;
 > >
 > >   public void endElement (String ns, String name)
 > >     throws SAXException;
 > to:
 > >   public void startElement (String nsPrefix, String ns, String name,
 > >                             AttributeList atts)
 > >     throws SAXException;
 > >
 > >   public void endElement (String nsPrefix,String ns, String name)
 > >     throws SAXException;
 > We can build ours DOM more easily this way dont have to buffer the other
 > namespace events.  I also would be surprised if at least 80% of SAX2 users
 > a) wouldnt mind this being present b) would probably use it

That was my original suggestion, but James Clark wisely pointed out
that it was possible to drop one of the arguments.  Consider the
following document:

 <html:p xmlns:html="">Hello.</html:p>

With my proposal, what you will get by default is

  startElement("", "p", atts);
  endElement("", "p");

Nothing too tricky there, and that's all that most apps will ever
need.  If you pass in a LexicalHandler and the parser supports it, you
might get a little more:

  startNamespaceDeclScope("html", "");
  startElement("", "p", atts);
  endElement("", "p");

I assume that's what you were thinking you'd have to cache, but that
would be wrong, since you could not with certainty map the Namespace
URI back to the original prefix used.  James's suggestion was that, at 
user option, the parser leave the original prefix on the name:

  startElement("", "html:p", atts);
  endElement("", "html:p");

This would never be enabled by default, but for the relatively small
class of apps that needed to know the original prefix, the prefix
would be available simply by splitting the name argument.

I like this approach because it doesn't throw the prefix in the face
of apps that don't need it -- to paraphrase Larry Wall, it makes common
tasks easy and uncommon tasks possible.

All the best,


David Megginson                 david at

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

More information about the Xml-dev mailing list