Lists Home |
Date Index |
- From: email@example.com (Alex Milowski)
- To: firstname.lastname@example.org
- Date: Thu, 19 Jun 1997 12:19:35 -0500 (CDT)
> Alex Milowski wrote:
> > ...it would be ideal if XML processors could produce a grove...
> Do you mean that the only output of an XML parser would be a grove?
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
R. Alexander Milowski http://www.copsol.com/ email@example.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 firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)