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

[David Brownell <david-b@pacbell.net>]

Miles Sabin wrote:
> 

I've been getting mail dropped lately -- I found your direct
reply to me in the (old?) lists.ic.ac.uk archive.


> * 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?)
and I think manual configuration of system or subsystem
defaults is likely to remain appropriate for a while.


> * A plug'n'play XMLReader factory which supports multiple
>   parsers and transparent adaptation of SAX 1 parsers.

More or less like the existing ParserFactory, except maybe
following Java conventions a bit better ("createXMLReader")
and throwing more appropriate exceptions?  Yes.


> * An extended ParserAdapter which exposes a SAX 1 parsers
>   support for validation.

That'd need a SAX1 extension ... ergo, SAX2?

Yes, Sun's proposed extension API does provide one solution here.
I don't much like it; depends on writing code, I'd rather have a
configuration file.

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.  (In
fact I'd as soon make that default different how SAX2beta has it.)


> * A couple of utility interfaces which bundle up the standard
>   SAX 2.0 feature and property identifiers.

Was there anything spoken against having some (standard) string member
for the new handler interfaces, like "SAX2_PROPERTY_ID" ??  That'd at
least handle those identifiers, though not the boolean features.

One of the more tedious tasks of updating my distribution to the
SAX2beta distribution was changing essentially every feature or
handler URI.  And removing as many of the now-deleted ones (like,
are all blocks of text buffered?) as I noticed.  So I'd be keen on
seeing the need for most such work go away.

In the case of handlers, the issue that David M. mentioned won't
exist -- new handlers get new class files anyway, so there's no
"single out-of-date file" type of version bug.


> Detailed descriptions and downloads can be found here,
> 
>   http://www3.mistral.co.uk/miles/

The bit about assembling configurations is something I'd defer until
there's more experience with requirements for such functionality.

- Dave