- From: James Clark <jjc@jclark.com>
- Date: Thu, 16 Mar 2000 08:56:16 +0700
- To: John Boyer <jboyer@PureEdge.com>
- CC: Jonathan Marsh <jmarsh@microsoft.com>, IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>, w3c-xsl-wg@w3.org
John Boyer wrote: > With respect, Mr. Clark, I don't understand how you can say > > 1) that Expr is the 'right' entry point for Xpath > 2) XSLT uses almost exclusively Expr > 3) the XPath transform is legal except for the starting context > > and then say > > 4) the XPath transform is "twisted" and "bizarre" > > Those are judgmental words to use. What's twisted and bizarre is using an extension function to get an initial handle on the source document, instead of using the mechanism that is built into XPath namely the context node. This will make XPath expressions used in your application confusingly different from XPath expressions used everywhere. Because you're not using the language in the way it is designed, there are likely to be subtle traps. For example, you will lose the ability to use the id() function (because functions are not allowed as the right hand operand of /). It's also going to be very awkward. Instead of something like e1|e2|e3|e4 you will have to write parse($input,true())/e1|parse($input,true())/e2|parse($input,true())/e3|parse($input,true())/e4 > By the way, the few problems solved by adding serialize and parse as > functions are, in my opinion, not critical. So feel free to recommend that > we move the parse and serialize as pre- and post-processing steps. That would be a big improvement in my opinion. James
Received on Wednesday, 15 March 2000 20:59:00 UTC