XML Property Set

[Peter Murray-Rust]

I think we have the basis of agreement on the overall architecture and it's 
important to move reasonably quickly with it.  From what I can gather the main
players are in agreement with the 4-block structure and - as a typical webhacker
- it seems to make sense to me.  [There are two places that I would hook JUMBO
into - the Event API and the Grove API.

It's VERY important to retain focus.  The 'Grove' approach should be similar
to the ReallySimple API [This was a propsoed Interface from James Clark on 
this list back in March under the 'Simple API' thread.  James produced an
interface that even I can understand, and that's what I hope we are
taking forward (in spirit at least).

In message <199706241418.JAA16855 at copsol.com> lex at www.copsol.com (Alex Milowski) writes:
> > 
> > |---------------|
> > |   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.

I think it's very important to keep this as lightweight as possible at this 
stage.  We're building prototypes (the language isn't stable - we don't know
what July 1 might include/omit :-).  So this API must make sense to a wide
range of people - it will be their main interaction with a parser.

> 
> > | 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.

I suspect that it will quite a small community that needs to interact with this;
specialist developers who care about the memory model, caching, interaction with
OBDs etc.

> 
> 
> > |----------------------------------|
> > |          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.

Good.
> 
> 
> > |----------------------------------|
> > |          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.  

Yes.  It hasn't been difficult to interact with the current parsers, but as
more come we shall get terminological slippage and this may cause confusion.
These APIs should hold the terminology fixed.
> 
[...]
> 
> I'm not certain I understand what you mean.  Can you give a more
> detailed example?

I think it would be very valuable to have some examples as soon as reasonable.
We shall then get a feel for the size of the property set (hopefully very small)
the factory model and so forth.  It would be very useful to have a V0.1 to
concentrate discussion and to get a feel for scale.

[WRT other discussions, I agree with those who are suggesting pure Java at 
present.  Although the extensions to other languages are probably fairly
straightforward, it all adds effort.  Java will prove the concept, show the
problems, and it is then much easier to extend and generalise.]

Remember also that there is/will_be a lot of work on XML-LINK, XML-TYPE,
XML-STYLE and we shall all get diverted when these crystallise.  A relatively
solid processing API will help all of these efforts as well.

	P.


-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

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)