RE: XPath transform

Hi Don,

<Don>
It seems to me that we keep coming back to the current implementations
of XPath being just from the point of view of supporting XSLT and
XPointer.
<snip/>
</Don>

<John>
Actually, no.  According to the Introduction to XPath, "The primary purpose
of XPath is to address parts of an XML [XML] document."  The design criteria
included support for both XPointer and XSLT, and the WG did not consider
other uses beyond the needs of XPointer and XSLT, but this was not intended
to exclude uses of XPath outside of XSLT and XPointer. To wit, notice in the
text of Section 6 of Xpath that XSLT and XPointer are used as examples of
specifications that use XPath: "XPath is intended primarily as a component
that can be used by other specifications. Therefore, XPath relies on
specifications that use XPath (such as [XPointer] and [XSLT]) to specify
criteria for conformance of implementations of XPath and does not define any
conformance criteria for independent implementations of XPath."

I do agree with your assertion that we are defining a use of Xpath that
differs from XPointer and XSLT.  However, as the above citation of
XPath/Section6 makes clear, it is not necessary to call this DSigXPath. By
analogy, we don't call it XPtrXPath and XSLTXPath.  It is XPath, and the
DSig specification is free to fill in the gaps.

The original specification of the XPath transform specified document order
for all nodes and attribute value normalization commensurate with the
actions of a validating processor.  We have bent over backwards to modify
this transform so that some could use existing tools rather than building
the DSig version of XPath.  But if the net result of this exploration is
that nothing we do will give us the control we need with the existing tools,
then I think we need to return to the simpler model of using document order.
It is OK for us to require an implementation that has properties specific to
DSig.

An XPath expression evaluator is, in and of itself, not so hard to create.
An XML processor which preserves document order is also not that hard to
create (e.g. a few lines of code removed from Clark's parser will do it).
The net result is that it is not that hard to create an xpath expression
evaluator that operates on document order.

The things I liked best about document order (in lieu of applying c14n) were

	A) it relied only on the rules of XML, XPath and DSig; those who want c14n
can put it in a separate transform.
	B) it has that do-not-mess-with property; we preserve the order of nodes as
given in the file from which the resource was obtained.
	C) it has a much lower processing overhead, which is generally good for
servers as well as low-capacity devices.
	D) it is much easier to create 'wizards' that help with the creation of
XPath expressions if document order is assumed.

So, unless there is some objection, I would be happy to change the XPath
transform so that it defines the transform in terms of document order.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

</John>

Received on Monday, 31 January 2000 13:15:30 UTC