Re: We need an XPath API

["W. E. Perry" <wperry@fiduciary.com>]

Here we go down the path of complexity and abstraction once again .  .  .

Christian Nentwich wrote:

> > 4) Define an XML representation of XPath expressions
>
> I don't agree with 4 (the representation should be hidden behind the API.. I
> think an API for executing queries should be good enough):
>
> 5) Work on DOM trees as well as with a SAX parser (DOM tree query support is
> essential in my opinion.. SAX alone is no good. What if your dom tree comes
> out of a database?)

In my opinion, Sean McGrath is on a much more promising road:

>Its me, Mr. Layers back again. Why not XPath -> WF XML and then a SAX API for
it just drops out?

I realize that this takes us right back to the syntax vs. semantics debate, but
we are once again looking for an extension mechanism which (as a, or *the*,
priority for some of us) is an expression of XML syntax. The glue or interchange
layer in Sean McGrath's proposal is, in fact, WF XML. That mechanism implicitly
requires a well-formedness parse as the first step in processing at each layer,
and a stream of SAX events is the simplest, lightest, and most neutral
expression of that parse. In fact, as a matter of local process optimization
those SAX events themselves may be routed through layered filters without much
violating the underlying philosophy of WF XML as the glue between layers.

To me, the real goal here is to find an XML-compliant mechanism for this (and on
this precedent, later) extensions to the XML family. I continue to believe that
the cardinal virtue of XML is that it is inherently eXtensible through Markup.
Once again, we are presented with a clear choice of employing that mechanism or
opting instead for the abstraction and complexity of an alien OM.

Respectfully,

Walter Perry