Re: XML Component API
>>I would say that MDSAX and something like the api that Oren Ben-Kiki is >working on, >>because they work at a different granularity, are quite complimentary. > >I'd rather have a single API for connecting XML processors, which would work >at both granularities, then one for "inside a document processor" and one >for "combining document processors", unless there's a very good technical >reason to separate the two. For all I care this single API might be based on >MDSAX, if that's appropriate. I don't think it is ever safe to ignore granularity and that APIs for different levels of granularity should be free to develop in different directions. I've seen proposals to the OMG which had URLs as separate CORBA objects, with remote-access methods for fetching the various parts of the URL. Closer to home, I've heard from several sources the idea that DOM elements should be implemented as CORBA objects, with support for independent retrieval/update. A reverse form of this problem is the overly simple api used for UNIX processes, where perhaps a richer and more flexible interface might have been helpful in the long run. (Yes, MS windows goes too far, IMHO, in the other direction.) With very low-level api, it is quite helpful if applications of the api can consist largely of inline code, and if the overhead for handling the interface is low. Efficiency considerations rule! At a high-level api, the applications can always make use of lower-level components to handle a heavy-weight interface. The real need is to be able to interconnect a wide range of components. When connecting various document processes, you want to be able to connect a document- flow with a SAX event flow. And in connecting various sources and sinks, you may need something like a UNIX pipe: a thread-safe event queue. But at the lower level, within a process, you want to be able to extend a base-level filter class and just add 10 lines of code to manipulate a specific type of event. And you do not want any extraneous overhead whatsoever. There is another consideration as well. Within an MDSAX-based process, it is reasonable to mandate that all filters implement the DocumentHandler interface and that the glue code for chaining various filters together always reside in a factory class which implements the MDFilterFactory interface. But when interconnecting different processes, you want to allow for a much greater range of implementations. There should not be a requirement that all the document processes within a single runtime use MDSAX internally, only that they can serve as either a source or sink for a document or a SAX event. You want a framework for this larger granularity into which you can plug almost any kind of document processor. (And in this case, the framework may be quite application-specific, though that doesn't preclude the development of a toolkit to help with the task.) Bill 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/ 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