Re: XML Java API Standardization

Alex Milowski (lex@www.copsol.com)
Thu, 19 Jun 1997 08:57:46 -0500 (CDT)

>
> 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@copsol.com
Copernican Solutions Incorporated (612) 379 - 3608