Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Yet another SAX2 observation
Yet another SAX2 observationActually, my preferred solution to this
particular problem is
not to offer _two_ representation of the namespace scoping
information ... it'd be to use only the "xmlns*" attributes.
Those start/end mapping calls haven't been useful to me at all.
And on the contrary, the need to deal with two representations
of the mapping scopes (which may or may not duplicate the info
in the other representation) has been an annoyance.
It's worth noting that while versions of stuff like LexicalHandler
and DeclHandler have been around for 18 months or so (for anyone
who has really been tracking "SAX2" discussions ;-) the namespace
support hasn't been as discussed -- or implemented -- as long.
The three different modes of namespace support are what I find to
be the most problematic part. Particularly when controlled by two
separate feature flags, and so there are four states -- one of which
has been declared illegal ("false, false"). And keep in mind
that those two flags control several other features beyond use
of the start/end mapping calls.
- Dave
----- Original Message -----
From: Box, Don
To: 'xml-dev@x...' ; 'David Megginson (E-mail)'
Sent: Sunday, March 12, 2000 6:36 PM
Subject: Yet another SAX2 observation
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. The current docs regarding calling
NamespaceSupport.pushContext at every startElement notification doesn't
work. Assume the following implementation of ContentHandler:
class me implements DefaultHandler
void startPrefixMapping(String p, String u)
ns.declarePrefix(p, u);
}
void startElement(...)
ns.pushContext();
}
void endElement(...)
ns.popContext();
}
}
This implementation chokes, since the pushing needs to happen at the first
startPrefixMapping, not at the startElement notification. Rather, to
implement this correctly, one must write the code as follows:
class me implements DefaultHandler
void startPrefixMapping(String p, String u)
ns.pushContext();
ns.declarePrefix(p, u);
}
void startElement(...)
// do nothing wrt context mgmt.
}
void endElement(...)
// do nothing wrt context mgmt.
}
void endPrefixMapping(String p)
ns.popContext();
}
}
I have a feeling this isn't what people had in mind. I actually think the
flaw is in ContentHandler, since the current design requires the
implementation to retain additional state in order to match up namespace
declarations with the elements they correspond to.
DB
http://www.develop.com/dbox
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|
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
|
|||||||||
