XML Java API Standardization

[Alex Milowski]

Ok, I'm going to write about the "vision" thing... so you have been warned! ;-)
 
> If you want a full-featured API that is going to interoperate for
> SGML and XML docs as well, the grove is the only way to go, so there
> is no need to have this discussion here on that subject.  What we're
> trying to do is, specifically for the case of Java XML processors, which
> evidence would suggest are going to be large in number and relatively
> lightweight, is simply to give them some shared machinery as regards
> elements and attributes.
> 
> For this kind of purpose, I think the grove formalism is massive 
> overkill; right now people can whip off XML parsers in a week, if
> we require them to master grove plans and property sets and so on,
> we're tripling the amount of time that has to be invested.

Agreed.  My real point is that we have to have a vision for where such
APIs are going.  The absolute *last* thing I want to have happen is to get
a low-level parser/event API and not be able to implement the more basic
grove on top of that.  Hence we need a vision of where such API are going
and what they will grow into.

I see a parser and event API as being the foundation of a much larger set of
APIs for XML, SGML, and DSSSL.

In light of this, here are some of my requirements:

1. The API should be componentized such that parser access and configuration
   is separated by event delivery and use.

2. Event APIs should be constructed in a way such that new properties of
   events and new events can be delivered within the same interface.  This
   will allow support of additional grove plans within the same interface.

3. There is a minimal set of grove plans from a DSSSL perspective that we 
   should conform to.  (I have a good idea of what these grove plans are but 
   I don't have the DSSSL spec in-front of me).  These grove plans will help
   define what events to deliver and what properties the events should have.

Suggestions:

1. Interfaces (sub-typing) is a preferred way to deliver such APIs.  We do
   not want to enforce an inheritance hierarchy.   Also, interfaces can easily 
   be made cross-language.

2. We should define the APIs within a reference architecture(s) rather than 
   just focusing on the communication between a parser and an arbitrary 
   application.  By using many common architectures we can understand the
   use-case scenarios for the API.  This is a similar exercise the the
   CRC cards in object-oriented design.

   
> At 12:20 PM 19/06/97 -0400, Peter Newcomb wrote:
> >As the SGML property set has already been published (in DSSSL, and
> >soon in the HyTime 2nd Edition) and is in use, I suggest that it be
> >used as a terminology reference for new SGML and XML interface
> >design.
> 
> This is part of the problem; last time I looked, the SGML property
> set was over 75 pages in length, and most of what it contains is
> just not interesting for XML parsers.  
> 
> If we could just agree, specifically for Java, how to talk to a
> few basic things (Element, Attribute, etc), this would be a huge
> step forward. -Tim

Yes, but we should start with the DSSSL specification.  Not to mention this 
*yet* again today, but the DSSSLTK implements about five grove plans.  I'll get
the list tomorrow when I have the reference information on hand and post
it here.

If we spend the time working from the DSSSL grove specification, we can 
ensure grove production.

If you want/need a more readable grove specification, try the grove guide
that I built.  The HTML version is at:

http://www.copsol.com/sgmlimpl/standards/gguide.html

and more generally at:

http://www.copsol.com/sgmlimpl/standards/

The grove guide re-orients the SGML property set from DSSSL in the 
opposite way that it is specified.  In the DSSSL standard, each grove
plan is listed and within the grove plan either new classes are defined
or properties are added to previously defined classes.  In the grove
guide, each class is defined and the properties are listed by grove
plan.

What we design and engineer today and label a standard may stick around longer
than we expect.  We shouldn't take too minimalist of an approach.  My
compromise is for a *reasonable* solution that has growth of the API
designed into it.

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex at copsol.com
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 at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)