[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Java API Standardization
> > Now that the number of XML processor implementations is increasing > rapidly, I would like to continue the subject of API standardization. I > have written a document which discusses the issue and presents an > informal proposal which continues the discussion of API standardization > for Java. > > The document is located at: > http://www.datachannel.com/ChannelWorld/XML/dev > > The first goal is to find a lowest common denominator for the current > implementations and abstract that to a set of interfaces such that a > developer could use this new API independent of an underlying > implementation of the XML processor and/or invest in learning the > particular benefits a specific implementation provides. > > I hope the site will serve as a convenience to the community and I will > maintain it as a summary of what is going on in this list. Any feedback > would be greatly appreciated. This is a work in progress. The greater > the contributions, the better it will serve its purpose. After having read the above document, I like to say: "You missed one!" The DSSSL Developer's Toolkit covers some of what the above document is trying to address (actually more since it is standardizing DSSSL). I developed this toolkit to be standardized and serve as a standard DSSSL API. The dsssl.grove package is intended to provide standardized programatic access to groves--the result of processing an SGML document. IMHO, it would be ideal if XML processors could produce a grove that a DSSSL processor could use. What is not contained in the current DSSSLTK distribution but will be in the next is a standardize parser interface. That is, access to some implementation that can be told to parse some system identifier and produce a grove. Also, note that in DSSSLTK there is a construct called a "Grove Constructor". This interface provides a means for groves to be build on different implementation technologies and used by the same parser without changing the interface. It is different than the "event handler" model but it shares some similarities. Essentially, the parser is abstracted from grove construction. Hence, you can build groves in databases as well as in-memory or whatever technology you choose without changing the parser. Also, all constructs in the DSSSLTK are based on interfaces. This allows different inheritance hierarchies to be used within the same distribution or for different class libraries to be mixed without getting into multiple inheritance issues. A node in a grove must implement two interfaces: node and its specific class. For example, an Element node *must* implement the dsssl.grove.node and dsssl.grove.Element interface. Remember, the DSSSL standard *has* a data model for SGML that can be pruned to provide a "lowest common denominator" data model for XML. Full source code and javadoc are available in the DSSSLTK distribution located at: http://www.copsol.com/products/ This is start at standardization for DSSSL from my point of view. I put this distribution together to allow others to contribute and create a standard API governed by some "higher body" and not Copernican Solutions or myself. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@c... Copernican Solutions Incorporated (612) 379 - 3608 xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (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
|