[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Ignorant and obsolete criticisms of SAX2 (probably)

• From: David Megginson <david@m...>
• To: xml-dev@X...
• Date: 15 Mar 2000 06:47:29 -0500

"Ean R . Schuessler" <ean@n...> 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@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/
***************************************************************************

• References:
  • Ignorant and obsolete criticisms of SAX2 (probably)
    • From: "Ean R . Schuessler" <ean@n...>

• Prev by Date: Re: Gutenberg Project <longish>
• Next by Date: Re: Gutenberg Project <longish>
• Previous by thread: Ignorant and obsolete criticisms of SAX2 (probably)
• Next by thread: DTD/XMLSchema Parsers
• Index(es):
  • Date
  • Thread