Re: ANN: SAX 2.0 extension proposals.
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format