Re: We need an XPath API

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

Christian Nentwich wrote:

> > 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
>
> To be honest, I'm a bit confused. Could you elaborate how this would
> help anyone who doesn't actually have the DOM tree represented as an XML
> file but gets it out of some data source ? I haven't been following the
> abstraction debate that much..

Sean McGrath diagrams a proposal at
http://lists.xml.org/archives/xml-dev/200103/msg00169.html as follows:

>Now lets think about a world in which (finally!) WF XML to
>WF XML transformation can be performed losslessly
>on instances that eschew the doctype.

>We have SAX/DOM (or whatever) APIs to access the
>data model produced by WF parsing.

>Now:-

>Defaulting / Fixed Attributes: WF XML -> WF XML
>"Entity" transclusion: WF XML -> WF XML
>Cross reference validation: WF XML -> WF XML
>Content model validation: WF XML -> WF XML
>HyTimish Architecture validation: WF XML -> WF XML
>HyTimish Architecture transformation: WF XM: -> WF XML
>Declarative Transformation with XSLT: WF XML -> WF-XML
>Imperative Transformation: WF XML -> WF XML
>Styling: WF XML -> WF XML -> Backend non-XML flow objects e.f. RTF

In the posting to which you responded, my point was that the input and the output of
each of these layers was explicitly WF XML--that is, the interchange or glue between
these layers is, unsurprisingly I should think, the syntactic common ground of XML
1.0. My only point about SAX events was that where various of these WF XML -> WF XML
transforms are executed in a pipeline under the control of a single supervisory
process, it may be more efficient to pipe SAX events between the transforms than to
return to XML text at the end of each step and then re-parse (presumably to SAX
events) at the beginning of each subsequent step. As a performance-enhancing
mechanism, that pipeline of SAX events does not appear to do much violence to the
philosophical premise here of WF XML syntax as inherently the common ground of XML
processing.

As for your question about content from a database or source other than XML text:
the premise of Sean McGrath's model seems to me to be that WF XML is the truly common
denominator, and therefore the necessary transitional form, between layers of
process. The point is precisely that such layered processing will not go in a single
step directly from database to DOM. To enhance the performance of a specific custom
application you might choose to build it directly from a specific database schema on
one end and to a specific DOM on the other, but that serves a different purpose than
the predictable interoperability of processing layers pipelined in custom
arrangements through the common syntax of WF XML.

Respectfully,

Walter Perry