RE: ModSAX: Proposed Core Features
Oren Ben-Kiki wrote: > >* What are the interfaces between components and how hard are they to > >implement? > > Basically the SAX callbacks, probably extended so that the full document > data is available (comments and so on). This seems pretty much a done deal. and also wrote: > >* Who assembles the components -- the application, the processor, or a > >third party? > > What I'm suggesting is we currently answer "for now, the application", and > provide a simple, lightweight, low-level API which allows it to do so. More > complex solutions could evolve later on. This seems to be in the SAX spirit. If the application assembles the components and the interface between them is SAX, what do we need that SAX filters don't already give us? In other words, does anything need to be done to OpenSAX (best name so far) to support this besides adding the ParserFilter interface? The other question that occurs to me is how useful/common it is to dynamically assemble a processor at run time. That is, are there really applications (outside of test environments) that allow the user to designate their parser at run time (or even installation time) and therefore need to cover any possible deficiencies in the chosen parser? What is gained by allowing the user to choose the parser? Note that this is a very different situation from, say, using different ODBC drivers. In the case of ODBC drivers, you are choosing a different source of data (type of database) and application writers have a strong incentive to support multiple databases through ODBC. In the case of XML, the source of data is always the same XML document and the choice of parser becomes a trade-off between speed, reliability, feature-set, etc. Since the application writer knows the feature set ahead of time, why not just hard-code the required parser and SAX filters and be done with it? (Yes, I know that "hard-code" is a bad word and I shudder as a write it, but I really am curious if anybody out there has a real-world application that allows users to change parsers and what the benefits of this are besides the ability to say, "Oh, look. I'm using a different parser.") In this view, the utility of SAX is not the ability to change parsers at run time, but to change them over time as reliability, speed, size, etc. of the parsers change. It also means that application writers can learn a single interface (SAX) and then choose parsers as they are appropriate to the application without having to learn different interfaces for different parsers. The ability to request features in OpenSAX allows the application to request processor behavior, which is slightly different from assembling a suitable parser. For example, if I have an application that doesn't need validation, but I the parser I want to use does validation by default, I would like to be able to turn that off. Just to be clear, I'm not necessarily against assembling processors based on a feature set. I just believe that it is far more complex than it appears at first glance and am not convinced that it's worth the trouble. -- Ron Bourret 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