Lists Home |
Date Index |
- From: Jonathan Borden <firstname.lastname@example.org>
- To: Sean McGrath <email@example.com>,"Simon St.Laurent" <firstname.lastname@example.org>, email@example.com
- Date: Wed, 27 Dec 2000 11:19:06 -0500
Sean McGrath wrote:
> At 06:05 PM 12/26/2000 -0500, Jonathan Borden wrote:
> >Simon St.Laurent wrote:
> > >
> > > Yes, but it might be interesting to create an 'XPath parser'
> which reads
> > > XPath and spits out SAX events, making these critters a bit easier to
> > > process and transform internally. Then maybe an XPath writer
> which takes
> > > those events and reports them as XPath again.
> > So what you want is an XPath grove parser.
> What would the grove approach offer that an XML notation approach
> would not?
What I mean by an XPath grove parser is very simply a parser that parses
XPath and emits SAX events; converting the XPath syntax into a *logical* XML
processing structure that can be manipulated by the SAX filter chain that we
all know and love. Anyone who has written a parser that emits SAX events has
worked with groves (whether you knew it or not :-)
The XPath grove simply refers to the logical structure of the XPath
character string as opposed to the actual character string. Such a grove, if
represented by a series of SAX events, can be manipulated by XSLT. To
distinguish the logical 'XML' represented by the series of SAX events (or
perhaps a DOM) from actual XML in a character stream, we use the term
'grove'. So the XPath need not be actually transformed into an XML character
stream rather parsed as a grove. An "XPath grove parser" in this case simply
parses an XPath and emits SAX events.
A notation is a way of naming a non XML or SGML structure but does not
itself handle grove processing. One might link a structure defined by a
notation to a grove parser in order to import such a structure into an XML
> I like the idea of a blessed XML expression of notations that are not
> natively XML (XPath, SAX events, MP3:-). Blessing XML notation
> for these allows implementers to implement XML import/export
> and allows integrators to join things together using their
> XML toolbox for the glue.
Notations alone do not provide for XML 'import' of non-XML data. Notations
are similar to MIME content-types, they simply provide for names of
external, perhaps binary, datatypes. A grove parser, on the other hand, is
what allows integration of non-XML data as defined by either a notation or
MIME content-type. Since EBNF is the most common and standardized format for
describing syntaxes I have suggested that a set of EBNF productions form the
property set for a grove for a given notation/content-type.
An explanation of such uses of groves in the healthcare field is available
in the slides from my XML Healthcare talk (see
http://www.openhealth.org/talks ). A description of the grove for XML itself
(using the XML 1.0 productions) is available at
The Open Healthcare Group