[
Lists Home |
Date Index |
Thread Index
]
- From: lex@www.copsol.com (Alex Milowski)
- To: xml-dev@ic.ac.uk
- Date: Mon, 23 Jun 1997 15:25:00 -0500 (CDT)
> Just to check I have it right...
>
> > An API architecture that I propose is:
> >
> > |---------------|
> > | Grove API | <<< I assume this has similarities to JamesClark's
> > |---------------| ReallySimple API ...
> > | Grove Builder |
> > | API | <<< different memory/storage models are implemented here.
> > |----------------------------------|
> > | XML Event API | << presumably fairly similar to NXP?
> > |----------------------------------|
> > | XML Parser API | << Corresponds to John Tigue's analysis?
> > |----------------------------------|
> >
> [...]
> > Now, I feel strongly that above APIs or what they become are developed
> > together. They can certain affect how each other is designed.
>
> I'd agree with this. Can they be developed rapidly or in
> parallel so that there aren't bottlenecks/hold-ups?
Yes, I believe that they can be developed in parallel. I for one can make the
commitment that we can develop a reference implementation of groves in
Java given that the Event API is standardized across XML Java parsers.
> > 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!)
>
> If I get this right it makes the DSSSL approach and the JavaClass-per-Element
> (as in JUMBO), very closely connected. The Grove API serves both purposes?
> If so, that looks very exciting.
Well, almost. The Grove API is *one* component of the infrastructure necessary
for a DSSSL system. In some senses, it is the most important. In the DSSSLTK
I opted for several APIs--one for groves, one for flow objects and flow object
trees, and one for the DSSSL engine. In the next version there will be
one for the parser implementation as well.
Groves allows us to deliver SDQL and DSSSL engines with minimal effort, but
there is still more to standardize.
For example, a simple DSSSL engine API might be:
public interface Processor {
SGMLDocument transform(SGMLDocument transformation,SGMLDocument doc);
FlowObject format(SGMLDocument style,SGMLDocument doc);
}
The DSSSLTK is a little more complex then this because it provides the ability
to "compile" transformations and stylesheets into Transformation and
StyleSheet objects.
My main point was that other APIs (DSSSL Engine for example) are *users* of
the Parser and Grove APIs. Hence, these should be able to be developed first
independant of the others.
==============================================================================
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)
|
