xml-dev - Re: ANN: SAX 2.0 extension proposals.

[Jim Layer <JBLayer@netscape.net>]

David Brownell writes:

> Miles Sabin wrote:
> 
> > * A means of querying an XMLReader implementations features
> >   without first having to instantiate an XMLReader.
> 
> I'm not sure I see a need for that.  So far there aren't so
> many implementations (those in my package, how many others?)

I'd suggest that Miles' proposal for this interface is more of
a forward thinking approach along the vendor neutral line
that resulted in SAX in the first place.
 
Without such a (lightweight) interface, there is no (standard)
means of determining parser feature support without creating an
instance of the parser. Running up a Xerces or Sun parser is
expensive in terms of time (anywhere from 900ms to 1.7 seconds
on the systems I have to target). This proposed interface cuts
the exercise of *finding* an appropriate parser down to around
100ms (or less) on these same systems (3 parsers in play for
this result) making this a relatively viable solution for time
sensitive data transactions (in cases where maintaining an
instance of an appropriate parser from transaction to transaction
is impractical).

> and I think manual configuration of system or subsystem
> defaults is likely to remain appropriate for a while.

Manual configuration starts to get ugly as the number of apps
and platforms on which they reside multiply. If each app maintains
a configuration file, all must be identified and changed when/if
the parser used is changed. Even if all locally developed apps
are designed to use a locally developed custom factory that
isolates them from this issue (custom factory config must *still*
be updated for parser change), this solution breaks down when
third-party software that depends on a parser is introduced.

> I'd like to see the SAX2 ("XMLReaderFactory") solution address
> this issue.  Also the "show XML names" issue -- I'd rather have
> that work "as delivered from the factory" rather than have to set
> the feature directly to "true", or always to configure something
> into the processing pipeline to stick some prefix back on.

Would be helpful if the XMLReaderImplementations.java create
method(s) took the extra step to set requested state (by default
or optionally). Save a lot of duplicate logic in apps.

[the following my (admittedly limited) treetop level
business-end-of-the-club view for the rest of you cookin'
along at 30,000...]

IMO (for what niggly bit that's worth) Miles' interface/factory
proposal elegantly evolves the original factory concept into a
clean, vendor neutral approach for creating parsers that does not
need to lean on configuration files (that require customization,
and then, where do/does they/it live?) or command line options
(more customization).

The time cost of using Miles' factory is relatively minimal and
it definately rounds out the vendor neutral aspect of SAX(2).
I'd suggest that it brings to (SAX) parser/reader creation what
SAX did to the event-driven parser API.

Both the potential issues of size (~50% increase over core SAX2
beta) and (build) dependence on Java V1.2.x could be easily
mitigated by separating (org.xml.sax.helpers) factory classes
from core SAX2, either as in separate jar or by providing *core*
and *full* release jars.

I've already been confronted with all of the issues Miles outlined
(except those related to Servlets, and those I'll have to deal with
later this year). Point being that they're not merely theoretical,
at least in my case. I'm surprised there has not been more of a
response (to his proposal) here - I wonder if many who would benefit
from this don't subscribe to xml-dev (or lurk archives).

I'll be crying in my brew if this stuff doesn't make the final cut.

Regards,

Jim Layer


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.