xml-dev - Re: XML Java API Standardization

[lex@www.copsol.com (Alex Milowski)]

> Alex Milowski wrote:
> > 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.
> 
> Alex,
> 
> I certainly agree, that a (complete) grove is probably
> the most powerful and complete way of accessing
> a documents data.
> 
> I am not convinced however, that it is always necessary
> to built a grove.

In my experience, the need to have a grove is often more the case then the
need to have an event stream.  I rarely have built SGML applications where
a grove did not simplify the processing.  Event streams are good for
extracting simple information or processing documents in a linear.  I like
to view a document as a data structure that I can manipulate.

I would be open to having a two-tiered API where there was an event oriented
API.  In fact, the GroveConstructor interface could be considered to be
this kind of low level API.

I we don't standardize grove access, we will all have to build our own
grove implementations at some point in time.

In addition, can you imagine the possibilities if simple applets could
turn around to a server, load a grove, and receive structured information
rather than name value pairs?  We need to address issues beyond "quick
browsing/processing" in a standardized API.

So, essentially, I agree.  It is not always necessary to have a grove.  It
a complex application, it is most certainly necessary.  Hence, we should
standardize that as well.

> 
> My view on this is :
> 
> -----------------------------------------------
> -               application                   -
> ----------------------------------            -
> -   grove/tree builder           -            -
> -----------------------------------------------
> -  event stream (Esis++)                      -
> ----------------------------------      NXP   -     
> -     core parser                             -
> -----------------------------------------------

I can envision a similar but more complete structure:

     DSSSL
  Application
----------------
-  DSSSL API   -      Complex Application
------------------------------------------------
-              Standard Grove API              -
------------------------------------------------
-             Grove Implementation             -
-           (Implementation dependent)         -
------------------------------------------------
-                  Grove Builder API           -  Simple Application
---------------------------------------------------------------------
-                            Event Stream API                       -
---------------------------------------------------------------------
-                               Parser API                          -
---------------------------------------------------------------------
-                           Parser Implementation                   -
-                         (Implementation dependent)                -
---------------------------------------------------------------------

The DSSSLTK covers most of the above with the except of an event oriented
API.  The GroveConstructor interface is really the Grove Builder API in
the above diagram.

Hence, what should be standardized is:

* Parser API
* Event Stream API
* Grove Builder API
* Standard Grove API
* DSSSL API

> You can always built a more powerful layer
> on top of an event stream. Furthermore we
> should also consider the work of the DOM
> group. Their results will have a considerable
> impact on our work as well.

Yes, but only if we properly componentize the APIs.

I'm not so certain about DOM.  It would be nice if it was a little more
open of a process.  DOM essentially means grove to me.

> If we can provide a flexible low level
> layer, we can always add more fancy and
> specialized post-processors on top
> of it.

Yes, but I want to standardize the "specialized" processors.

For example, consider the situation where as an application developer
you could be assured that a grove implementation is available in a 
browser framework.  In that situation, you could deliver an applet (or
whatever) that loaded a grove but relied on the browser to provide the
infrastructure for "knowing" how to load/store/etc. a grove.

We are developing and standardizing infrastructure as well as APIs.

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