xml-dev - RE: SAX2: start/endPrefixMapping

["Box, Don" <dbox@develop.com>]

Title: RE: SAX2: start/endPrefixMapping

> -----Original Message-----
> From: David Megginson [mailto:david@megginson.com]
> Sent: Wednesday, March 15, 2000 4:08 AM
> To: xml-dev@xml.org
> Subject: re: SAX2: start/endPrefixMapping
>
>
> Box, Don writes:
>
>  > In trying to properly implement the in-scope namespaces Infoset
>  > property, I found the following inconvenience with SAX2. The
>  > ordering of startPrefixMapping and startElement requires the
>  > implementation of ContentHandler to either (a) create a new
>  > "scoping context" for each namespace declaration or (b) keep a data
>  > member around to note that a new element has started.
>
> Yes, I understand the problem, but for most apps, it's more
> convenient
> to know the mappings *before* the startElement event so that they can
> process attribute values that are QNames.

Agreed. That's why I've come to believe that the namespace decls should be delivered as a parameter to startElement just as attributes are delivered now. This satisfies the "I need to see all of the prefix mappings before processing QNames" problem and also fixes the "which GROUP of decls are in scope" problem I mentioned in my earlier post.

> Actually, I hadn't intended the NamespaceContext class to be used for
> keeping track of this kind of information on the client side
> -- it was
> meant only as a convenience class for driver writers, but that only
> goes to show that users always think of new ways to use stuff.  For
> what you want to do, I think that a simple boolean flag is the best
> approach:
>
>   class me implements DefaultHandler {
>     void startPrefixMapping(String p, String u) {
>       if (!contextPushed) {
>       ns.pushContext();
>       contextPushed = true;
>       }
>       ns.declarePrefix(p, u);
>     }
>     void startElement(...) {
>       if (!contextPushed) {
>       ns.pushContext();
>       }
>       contextPushed = false;
>     }
>     void endElement(...) {
>       ns.popContext();
>     }
>
>     boolean contextPushed = false;
>   }
>
> This doesn't add much complexity for your case, but keeps things easy
> for people who just want to process QNames in attribute values.

However, it took me several passes at writing this code to get it right without simply calling pushcontext on every startPrefixMapping. My guess is other people will have similar problems (insert comment on ineptness of DB here). To me, that indicates that the protocol of ContentHandler could be improved to make the job of implementors easier with no negative impact on consumers.

BTW, I think you sell SAX2 short by framing the world in terms of driver writers and the rest of the world. I think ContentHandler and friends make as much sense to consume as they do to implement. Maybe I'm crazy, but I view ContentHandler et al as yet another isomorphism of the Infoset and think it is as viable a way to pass XML documents around as a DOM node.

DB
http://www.develop.com/dbox