SAX2: Namespace proposal

David Megginson david at
Sat Dec 18 22:57:10 GMT 1999

In my last message, I summarized some of the major positions that have
emerged on Namespace support in SAX2.  I've done a lot of thinking
about this recently, partly because Namespace support is a technical
requirement for two of my customers.

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.

That said, I think that the best solution in SAX2 will be to allow
either or both Namespace-qualified and raw XML names.  People seem to
want both, and although I *strongly* disagree, DOM2 has decided to
provide what should be irrelevant information about the original
prefix used.

Anyway, here's what I'm suggesting.  Please take a couple of Rolaids
and maybe even a Gravol before you look at this, because while it's
functional, it's not at all pretty...

1. From org.xml.sax2.DocumentHandler

  public void startElement (String name, String namespaceURI,
                            String localName, AttributeList atts)
    throws SAXException;

  public void endElement (String name, String namespaceURI,
                          String localName)
    throws SAXException;

2. From org.xml.sax2.AttributeList

  public String getName (int index);
  public String getNamespaceURI (int index);
  public String getLocalName (int index);
  public String getType (int index);
  public String getValue (int index);

  public String getType (String name);
  public String getType (String namespaceURI, String localName);
  public String getValue (String name);
  public String getValue (String namespaceURI, String localName);


a. A parser has the right to supply only cooked Namespace information, 
   only raw XML 1.0 information, or both, as long as it does so
   consistently.  It will be possible to query and set the parser's

b. The Namespace URI will be null when there is no Namespace declared
   or none available.

c. If the Parser is delivering raw XML 1.0 names, the Namespace
   declarations (xmlns*) will be included in the AttributeList but
   both the Namespace URI and the local name will be set to null, and
   getType(String, String) and getValue(String, String) will always
   fail (even with null arguments).

d. There will probably also be a NamespaceHandler to report the scope
   of Namespace declarations, but it may be possible to roll that into 

Here's a short example:

  <note xmlns:html="">
   <html:p>Hello, world!</html:p>

If the parser does only raw XML 1.0 processing, it will report the
following events (omitting a little whitespace for clarity):

  startElement("note", null, null, [ATTS]);
  startElement("html:p", null, null, [ATTS]);
  characters("Hello, world!")
  endElement("html:p", null, null)
  endElement("note", null, null)

If the parser does only Namespace processing it will report the
following events (again, omitting a little whitespace):

  startElement(null, null, "note", [ATTS]);
  startElement(null, "", "p", [ATTS]);
  characters("Hello, world!")
  endElement(null, "", "p")
  endElement(null, null, "note")

If the parser does both kinds of processing, it will report the

  startElement("note", null, "note", [ATTS]);
  startElement("html:p", "", "p", [ATTS]);
  characters("Hello, world!")
  endElement("html:p", "", "p")
  endElement("note", null, "note")

This is kind-of painful, I know, but please remember that SAX is meant
to be the equivalent of a low-level device driver, not an elegant,
high-level API (though those can be and have been built on top of it).
A higher-level API would be free to ignore the raw XML 1.0 names, and,
in my opinion, would probably be wise to do so.

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