ANN: SAX 2.0 extension proposals.

[Miles Sabin]

David Megginson wrote,
> Miles Sabin wrote,
> > * 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.

OK, that's one way of doing it. But I don't think it'd be
a good choice, because it really doesn't get along well with
factories ... a standard SAX one, or custom ones.

What's the problem with adding a new interface?

> 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.

OK, but then a filter isn't a standalone entity. For example,
creating one via the XMLFilterImpl default constructor and
then invoking parse() would, unlike standalone parsers, throw
a NullPointerException. I wouldn't expect a filter to have
an XMLReaderImplementation associated with it, because it isn't
really an XMLReader implementation in the ordinary sense.

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

Well, you can't enforce _anything_ ... it is, after all, a
matter of convention that java XML parsers typically implement
org.xml.sax.Parser. If SAX 2 requires it, then it has to go in
if people want to be interoperable.

Hmm ... static methods just aren't the right way of going
about this anyhow.

> > * 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.

Maybe not in the SAX _core_, but I think it does belong in
_SAX_. I think you might be worrying a little too much about
footprint here (is it a general purpose API or are we
targetting palmtops and embedded devices?), but even if you're
right we can just split SAX into a core and a number of
optional modules. I'd be quite happy to see a factory moved
to the org.xml.sax.ext package and made an optional feature.

> > * 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.

Sure, you can't tell from an arbitrary instance of Parser
whether or not it supports validation. But typically there will
be contextual information hanging around somewhere which would
allow a boolean validating/not validating flag to be passed to
a parser adapter. I've got this working quite nicely for
AElfred, and IBMs and Suns parsers ... it's really not that
hard.

And again, if it doesn't belong in the core, that's fine.
Arguably the current ParserAdapter doesn't either. So let's
just move it to an optional package.

> > * 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.

Those two interfaces account for 1304 bytes uncompressed or
695 bytes when jar'ed. I'm all in favour of SAX being
lightweight ... but anorexic?

The reason I put them in is that I found use of the literal
Strings to be extremely error prone ... the contents of a String 
literal can't be checked by the compiler there's no way it can 
help me. On the other hand if I misspell a symbolic String 
constant identifier I get a helpful error message telling me to 
fix the problem.

> 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.

So long as none of the identifiers are removed, the interface
will be correct, albeit not complete. I don't see that as a
problem.

Can you give me some examples of _core_ SAX features that you
think could be added without a new SAX release? Schema support?
surely that'd need an extended API too?

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin at cromwellmedia.com          http://www.cromwellmedia.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.