OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SAX namespace handling underspecified?

While working on a SAX-based XInclude processor, I got somewhat confused about the guaranteed behavior of startPrefixMapping() and endPrefixMapping() in ContentHandler, particularly when these methods are called. 

The API docs and the SAX web site say more or less the same thing:

In addition to those events, SAX2 reports the scope of Namespace
declarations using the startPrefixMapping and endPrefixMapping methods,
so that applications can resolve prefixes in attribute values or
character data if necessary. The callbacks look like this:

      public void startPrefixMapping (String prefix, String uri)
        throws SAXException;
      public void endPrefixMapping (String prefix)
        throws SAXException;

For the above example, the XML reader would make the following callback
before the start-element event:

      startPrefixMapping("html", "http://www.w3.org/1999/xhtml")

The XML reader would make the following callback after the end-element event:


The rest of this document applies only to SAX2 applications with special
requirements, such as text editors.

The API docs add:

Note that start/endPrefixMapping events are not guaranteed to be properly nested relative to each-other: all startPrefixMapping events will occur before the corresponding startElement event, and all endPrefixMapping events will occur after the corresponding endElement event, but their order is not otherwise guaranteed.

I am especially concerned about that last phrase, "their order is not otherwise guaranteed."  That seems too weak. I suspect the intent here was essentially the same as saying attributes are unordered. In other words, the order of startPrefixMapping calls for namespaces declared on the same element is unspecified. However, what it actually says is a lot more. In particular this implies that it is acceptable behavior for a parser to invoke startPrefixMapping() well before the prefix actually comes into effect. For example, consider this fragment:

  <A>some text</A>
  <B xmlns:c="MyURI">some text</B>

I see nothing in the docs which would prohibit startPrefixMapping("c", "MyURI") from being called BEFORE startElement("", "root", "root" atts) even though the prefix is not in scope there. 

Obviously this behavior would be wrong. I doubt any parsers are behaving this way. I think this is just a documentation fix to make it clear that the startPrefixMapping() must be invoked immediately before the corresponding startElement() method, possibly with other relevant startPrefixMapping() methods intervening but no other methods. Comments? Thoughts? If there anything I've missed here? 


| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |