[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] ModSAX: Proposed Core Features
Bill la Forge <b.laforge@j...> wrote: >On a more serious note, > >I think we need a new ParserFactory... ModParserFactory? XParserFactory? >It should use ParserFactory to create a Parser and then check to see if the new >extension is supported. If not, it proceeds to wrap the parser so that it looks >like a ModParser. > >Note that this compatibility wrapper will effectively be a filter. I think you've hit on something important here. The Mod/X/Xtra/E-Sax thread has focused on "how to access extra functionality which is already available within a particular SAX parser implementation". This might be the wrong question to ask. Shouldn't it be "how to I obtain an instance of a SAX parser which provides the features I need", instead? This is a subtle but important shift of focus. Today one can obtain an instance of a SAX parser by using the ParserFactory. Now suppose my application needs an order of a namespace aware parser, character normalization on the side, and don't spare the comments, please - how would I go around creating such a thing? Note that this issue contains the original one; one needs to be able to access the extra features. But it goes beyond it. It might also help to constrain some design choices. Take for example the issue of naming features. Today ParserFactory uses the string "org.xml.sax.parser" as an identifier for the feature "take an input source and convert it to SAX events". The format of this particular string was chosen since it is usable as a key in a properties file. Wouldn't it be reasonable to say that whichever way Mod/X/Xtra/E-ParserFactory works, it will use the same approach - that is, use Java-like package names to identify features, so that it will be possible to provide default implementations using property files? I know this would be hard for the URI camp to swallow :-) but isn't it worth it? As to the issue itself, the way I see it there is one major question to be decided first. Are the extra features independent of each other? If they aren't, we are in trouble. How do I know that pushing a filter implementing feature X on top of a parser implementing feature Y doesn't break that feature? What if one feature depends on another? Should there be a way to describe the relationship between features? How? At any rate, the goal should be some registry of "parsers" and "filters" with an appropriate API so that it would be possible to ask for a certain feature set and obtain a "parser" instance. IMVHO as far as this registry is concerned, the basic SAX events interface and the input source interface should be on equal ground with the other features. This could be a flexible framework allowing to create processing chains such as using DOM as input/output of the chain, making XSL processing a core "feature", and so on. Has anything similar been done in a different field, so we could reuse the design lessons there? It seems like a pretty generic "stream processing" problem. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|