xml-dev - Re: XML syntax for XPath?

[Ken MacLeod <ken@bitsko.slc.ut.us>]

Sean McGrath <sean.mcgrath@propylon.com> writes:

> 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 in 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?

If you take the simple approach to groves, the advantages are that you
get a really simple set of data objects representing the parsed XPath,
and simple sets of data objects are trivially serialized using any
common format (XP, RDF, etc.).

For a parsed XPath, for example, the result would generally be a list
of steps, each step with an axis, node test, and a list of zero or
more predicates, each predicate an expression tree.

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

An advantage of unique XML notations per spec is generally terseness
of the resulting XML.  A disadvantage of unique XML notations per spec
is the necessity of implementing readers/writers for each one
individually.

Adopting an "Info Set" approach for notations that are not native XML
would make support in many languages either incredibly simple, or at
least not complex.  In Python, for example, reading and writing XML in
a known format, according to an info set, and converting into and out
of objects is almost a gimme.  In Java, it's not too difficult either,
even if one goes as far as dynamically generating classes to provide
convenient getters and setters for the data model.

An "Info Set" approach can also make non-language support easier too.
The effect of having a generalized format for serialization would make
reusable patterns of XSLT transforms fairly common.

  -- Ken