[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2: start/endPrefixMapping

  • From: "Rich Anderson" <rja@a...>
  • To: <xml-dev@X...>
  • Date: Wed, 15 Mar 2000 23:06:01 -0800

implements defaulthandler
Title: RE: SAX2: start/endPrefixMapping
>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.
 
Having implemented this already I found the approach both logical and simple to implement.  My life would be more hassle taking the approach you suggest, and would probably lead to a performance drop.  Have others had similar problems to Don ? Also, I'm sure I'm not the only one that wants to go back and undo lots of changes at this late stage ;)
 
>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
 
For interest, why would I want to use SAX2 pieces in the DOM when I can just pass around DOM nodes ?
 
Cheers,
 
Rich.
 
 
 
 
----- Original Message -----
From: Box, Don
Sent: Wednesday, March 15, 2000 1:58 PM
Subject: RE: SAX2: start/endPrefixMapping

> -----Original Message-----
> From: David Megginson [mailto:david@m...]
> Sent: Wednesday, March 15, 2000 4:08 AM
> To: xml-dev@x...
> 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



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.