ANN: SAX 2.0 extension proposals.

[Jim Layer]

David Megginson <david at megginson.com> wrote:
> Miles Sabin <msabin at cromwellmedia.co.uk> writes:
> > * A means of querying an XMLReader implementations features 
> >   without first having to instantiate an XMLReader.
> 
> That's not too hard: it would take only a few static methods.  There
> are a couple of issues, though:
> 
> 1. For a filter (which may be more common than a root reader), the
>    features available depend on the features supported by the parent
>    -- in other words, you cannot know what features are supported
>    *until* the reader is instantiated.

Wouldn't this depend on the design and / purpose of the filter (maybe I'm
confusing semantics of filter / adapter here so I'll use "wrapper" as a
generic)? If the wrapper requires a reader *instance* to create the wrapper
then the query / selection process would be handled somewhere else and this
wouldn't seem to be an issue. If the wrapper handled creation, it could use
the proposed factory to create. If it was more of an adapter, couldn't it
simply implement and pass through?

> 2. You cannot enforce static methods with an interface, so they would
>    have to be a matter of convention (like a no-argument constructor).

I was pushing static as convention initially, but I believe Miles has a better
approach with the interface. Assuming similar performance (I haven't directly
compared yet), the interface seems more appropriate.

> > * A plug'n'play XMLReader factory which supports multiple 
> >   parsers and transparent adaptation of SAX 1 parsers.
> 
> Does this belong in the SAX core, or should it be a higher-level app?
> I ask because I'm trying to keep the core sax2.jar as small as
> possible, since it will usually be only a minor part of an app.

I certainly wouldn't have a problem with a core / optional split (two jars? or
an implicit you-can-tear-this-out if space is a problem?). I've noticed that
quite a few parsers wind the SAX classes into their jar and you end up (in
multiple parser cases) with several copies of SAX anyway. If it is split, I
would like to see at least the meta-information interface included in the
core. 

> > * An extended ParserAdapter which exposes a SAX 1 parsers
> >   support for validation.
>
> I don't know if this belongs in SAX1 per se, since there's no
> way to know in the general case.  People writing adapters for 
> specific SAX1 parsers (where validation is known) can extend 
> ParserAdapter to add that information.

Maybe SAX1Impl and ValidatingSAX1Impl could simply serve as illustrations of
the technique. The current implementation makes it easy to test with current
(SAX1) parsers but I'd as soon see the system property related logic removed
from ImplEnumeration (even though it does provide more flexibility, at least
on paper - I didn't use the system property thing even with the SAX1 factory)
in the interest of performance and / or streamlining (assuming tearing it out
*does* speed things up - haven't checked that out either). You have to fool
with CLASSPATH to add another parser anyway and it's easy enough to field a
custom jar earlier in the CLASSPATH to produce the effect.

> > * A couple of utility interfaces which bundle up the 
> >   standard SAX 2.0 feature and property identifiers.
> Two issues here:
> 
> 1. I'm trying to limit bloat.

I'll be giving up the 695 bytes one way or the other (for the reasons Miles
stated and 'cause it seems more "readable". Rather see it built in than roll
my own. BTW Miles, shouldn't those strings be "static final"?

> 2. I expect that the list of core feature and property identifiers
>    will be able to grow *without* a new SAX release, so the class
>    would become outdated.

Easy enough then for the users to deal with additions in their own fashion
until / unless there *is* another release (maybe when the deprecated stuff is
tossed in the ash can ;-).

Miles's proposal, if incorporated into SAX2 and if SAX2 is embraced by the
parser builders as universally as was SAX1, fills a portability gap that,
prior to this, required custom logic. Using the factory, I should be able to
field XML related middleware on both UNIX and that Other Platform <grin/>
without (or at least with less) configuration nonsense. This also lets me
handle multiple parser (sorry, *reader*) scenarios elegantly where I do
control which ones live on a particular class of system and what each should
be used for (small/fast vs big/full-featured). While performance *is* a
consideration today (I am working at shaving a few hundred ms here and there
for a couple of apps that need to be *very* hot), I expect this to become much
less of a concern fairly rapidly as the user base continues to update
hardware.

I wouldn't expect Miles' stuff to hinder adoption of SAX2 by the parser folks
and it might even help some by extending the abstraction to reader creation.
 
BTW Miles, thanks for the nod, but all should know that my *bit* was pretty
darn insignificant...

Well, there's my quarter-cents worth. Maybe more when I've had some time to
give all this stuff more than a cursory ride...

Regards,

Jim Layer




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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.