[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
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 -----
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!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
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.
|
|