----- Original Message -----
Sent: Wednesday, March 15, 2000 1:58
PM
Subject: 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
