xml-dev - Re: XML Property Set

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

> 
> |---------------|
> |   Grove API   |   <<< I assume this has similarities to JamesClark's
> |---------------|             ReallySimple API ...

I'm not certain what the ReallySimple API is.  I was think along the lines
of the DSSSLTK dsssl.grove package.

> | Grove Builder |
> |     API       |   <<< different memory/storage models are implemented
> here.

Yes, exactly.  The Grove API is abstract and the Grove Builder API hides the
exact implementation methodologies for constructing grove objects from the
rest of the world.


> |----------------------------------|
> |          XML Event API           |  << presumably fairly similar to
> NXP?

Potentially.  I assume there will be some "grand convergence" on this between
parsers and the needs of a grove.


> |----------------------------------|
> |          XML Parser API          |  << Corresponds to John Tigue's
> analysis?
> |----------------------------------|

Yes, and maybe more infrastructure if we are up to it.  IMHO, this API should
provide the ability for different parsers to be *configured* for use within
an application.  Hence, this should be an abstract component that is
complete enough to allow most (if not all) applications to not have to
know the implementation details.  

We could use a factory design pattern here.

> I guess the two bottom layers and the connection between 
> Event API and Grove Builder API are my call.

Potentially.  I would guess that there could be a reference implementation of
an event handler that "knows" how to interface a grove builder.  It is
probably not true that *all* grove builders can be accessed the same.  For
example, in a database situation, extra work may be necessary in the connection
of the events to the grove builder. 

> Let me ask you :
> 
> Should we go for a pure event oriented API, like it is now 
> implemented in NXP (and leave it up to the next layer to create the 
> objects) or should we have creator methods that would be set in the
> event 
> API like now the Esis object is set (setEsis) in the parser. These
> methods 
> would be called in case of a specific event and the result of this 
> method call would be send to the application via the event interface. 

I think the event API is the most abstract and lowest level for a parser.  In
this manor, applications that do not need "grove objects" will not have to
have them created within some implementation. 

SP, for example, has quite an extensive event-oriented API.  Each event has
a great deal of detail (basically, everything there is to know).  It is
fairly easy to access the high level semantics of these events.  Low level
semantics like document strings--character for character representations of
the event--are a littler more work.  This is a design decision that we have
to make.

We could have two event APIs--one for document string access and one for
high level access including document string information, but that could
get far to complex.  One might also beg the question of why we need the
document string separated out when you can get it from the high-level
events.

> 
> For instance we would have an interface :
> 
> public interface Constructors
> {
>    public Element createElement();
>    public Attribute createAttribute();
>    ...
> }
> 
> Element and Attribute etc. will probably be subclasses of Node,
> as per James' simple API. Node, however, should be defined
> very generally so that we don't *have* to think about 
> DSSSL when want to talk about/use a node.
> 
> An event-producer class conforming to the Esis(++) interface would need
> to
> implement a method : 
> 
> public void setCreator(Constructors constr);
> 
> It would work then like : 
> 
> a.) parser recognises a certain tag
> b.) calls the appropriate creator method to create an 
> object of class element
> c.) sends the created object to the next layer via
> the event producer

Well, the above example is similar to the GroveConstructor class in the
DSSSLTK.  The GroveConstructor is different in that it trys to only allow
sub-node objects to be created from appropriate parents.  For example, the
document element can only be created by passing in the SGMLDocument node.
An element can only be created by passing in the parent of the element.

> 
> An alternative to the creator methods would be to
> set the objects to be created via a Hashtable of Strings.
> Then the objects would be create via their "name".
> 
> For instance an entry in the hashtable would look 
> like : "Element" -----> "dsssl.Element" and the
> result would be the creation of an object of type
> dsssl.Element for the "event" Element.

I'm not certain I understand what you mean.  Can you give a more
detailed example?

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