Cart
[Home] [By Thread] [By Date] [Recent Entries]
Box, Don writes:
> 1) The feature mechanism is busted wrt the two namespace-related
> features. It assumes that the ContentHandler interface will only
> be called by an XMLReader implementation. This makes it tough for
> folks who want to use ContentHandler (and friends) as a generic
> interface for modeling the Infoset as a stream of method
> invocations (see David Brownell's stuff for an example of one such
> architecture), since one doesn't know generically whether or not to
> deliver namespace declarations as attributes or not. In general,
> the "consumer" of ContentHandler should be able to interrogate the
> namespace management policy of the receiver of the SAX events.
In general, I've tried to keep the information flow in SAX one-way,
though we violated that with EntityResolver.
If we were to make such a change, we would have to allow other sorts
of queries as well, so a more general client-side
get/setFeature/Property would make the most sense -- why make
Namespace processing a special case?
That said, I'm not comfortable making such a major structural change
this late; I think that it is more suitable for an architectural layer
built higher up (where, maybe, the ContentHandler can register itself
somehow).
All the best,
David
--
David Megginson david@m...
http://www.megginson.com/
***************************************************************************
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/
***************************************************************************
|
