xml-dev - Re: XML Property Set

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

> > In my grove-illiterate opinion, yes!  The PropertySet is a sword of Damocles
> > hanging over these discussions.  It's clear that we can't have all 70+
> > properties.  IF (and I hope it's not a big IF) we can agree on a subset
> > of the property set then we don't have this problem dissipating the
> > discussion every time we get close :-)
> 
> It shouldn't be a big IF at all. Deciding what to rip out isn't too difficult. 
> The only problem lies in agreeing on how to do the additional classes (like 
> XMLDECL) needed and how (or if) the properties should be modularised.
> 
> > James Clark came up with a grove subset about 3 months back (have a look in
> > March xml-dev) in response to one of my typical blunderings for information.
> 
> I'll go back and check that. JamesC would be in a MUCH better position to write 
> an XML property set than me!

Well, I'm going to make an offer.  I've spent the better part of a year 
working on and with a Java-based API for groves.  I am certain that I can
create an interface from this (if not take it wholesale) for the XAPI and
groves.  So, my offer is that I can come up with a draft and "the James's"
and the lot can validate if I am on the right track.

I am fairly certain that at this point in time we should not say "maybe later"
to groves.  We should standardize parser access, event interfaces, and groves
at the same time.  We have enough developers with experience in all of these.

An API architecture that I propose is:

|---------------|
|   Grove API   |
|---------------|
| Grove Builder |
|     API       |
|----------------------------------|
|          XML Event API           |
|----------------------------------|
|          XML Parser API          |
|----------------------------------|

They are described as follows:

XML Parser API:

   Provides interfaces to instantiation and use of XML parsers such that
   a new XML parser can be integrated with existing application potentially
   with their knowledge.  This might allow a user to configure an application
   with (in Java) the class name of the XML Factory or whatever.

XML Event API:

   Provides an interface to allow XML parsers to deliver events to arbitrary
   applications.  My suggestion here is that we consider two kinds of APIs
   or at least constructs.  First, there is the idea of the "document string"
   which is the exact character for character representation of each
   construct.  Second, is a semantic event like "start element".  Both are
   useful depending on what one is doing.

Grove Builder API:

   This API bridges the gap between the event API and a grove.  Essentially,
   the algorithm for building a grove is most likely the same regardless of
   the implementation technology used to create the grove.  Hence, a standard
   event handler could be defined as well as an interface to allow different
   grove implementations to be used (for example, a JDBC grove and an in
   memory grove).

Grove API:

   This API, obviously, provides access to XML groves!

Again, my suggestion is that we take advantage of interfaces in XAPI.  
Interfaces will allow us to mix inheritance hierarchies in the above four APIs.

Now, I feel strongly that above APIs or what they become are developed 
together.  They can certain affect how each other is designed.

If we have these four APIs, we have the fundamental building blocks for all
kinds of XML applications--both simple and complex.  In addition, we have
the basic infrastructure for DSSSL!  (Ah, you can see my motivation now!)

==============================================================================
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)