Well, no, not necessarily. I think that such an API standardization should
also standardize grove production/use. I would like to be able to
guarantee that any conformant XML/Java/API environment is able to produce
groves if I *need* them.
> My use of XML is very lightweight and, from my position of minimal
> knowledge about groves, seems like I would have to pay some
> price in processing time or system resources for an XML parser to
> produce a grove for one of my "documents" when some very simple
> output would do.
Yes, you pay *some* price. There is a point in which the grove-based
processing paradigm is far more efficient than event oriented for more complex
tasks. The definition of "more complex" isn't that big of a leap. Simply
put: If you want to do *any* non-linear processing of XML, you are going to
find groves *far* easier and potentially, with SDQL (Standard Document
Query Language -- from DSSSL), it may be more efficient than building
ancillary data structures in addition to the events being received.
In a previous e-mail, I detailed an API architecture that I think would
work. Essentially, it is DSSSLTK with another couple of APIs on the
bottom of the stack. In my development, I made the design decision that
groves were what I needed to standardize since everything in DSSSL is groves.
I'm certain willing to add to this and standardize everything before that
as well.
==============================================================================
R. Alexander Milowski http://www.copsol.com/ alex@copsol.com
Copernican Solutions Incorporated (612) 379 - 3608