xml-dev - Re: Ignorant and obsolete criticisms of SAX2 (probably)

[David Megginson <david@megginson.com>]

"Ean R . Schuessler" <ean@novare.net> writes:

> 1. Why are there both features and properties? Can't a Feature be
>    modeled as a Boolean form of a Property? Doesn't this more
>    accurately represent the situation of Features that are
>    recognized but not present? (ie. False but not null)

Probably historical -- originally there were just features.  Keeping
features as a special case helps avoid a little indirection and
provides a bit of type checking for a very common case, though I know
it's theoretically less than pure.

> 2. What is the suggested way for handling request specific metadata
>    from the containing application context? More simply, if I am
>    going to generate an InputSource from a HttpServletRequest how
>    should I provide SAX Filters/Readers access to the HttpServlet
>    objects?

I'd recommend not, at least not in the general case -- filters should
see only a stream of events flowing through.  Now, if it happens that
your filters are specifically designed to work with servlets (for
example), then you can pass them all a shared application context
encapsulate in an object; generic filters shouldn't need that, though.

> 3. Since an XMLReader is a thing which has no SAX parent because it 
>    reads from a native format, shouldn't an XMLWriter be a thing
>    which has no SAX children because it writes to a native format?
>    Shouldn't SAXFilter then be the aggregate of those two
>    interfaces?

I don't think so, because SAX events flow in a single direction; all
of the handlers together form the SAX writer.

> 4. If it makes sense to query up the SAX chain to detect
>    capabilities in parents, shouldn't you also be able to query
>    down the SAX chain to detect capabilities in children? This
>    would seem especially useful with regard to Filters that
>    generate inlined code wanting later compilation.

Don Box has suggested the same thing, and I've replied to him (on the
list) in more detail.  Personally, I prefer to keep the information
flow mostly one-way (except for EntityResolver), to make life as
simple as possible for application writers.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************