- From: John Boyer <jboyer@PureEdge.com>
- Date: Thu, 16 Mar 2000 13:57:54 -0800
- To: "Jonathan Marsh" <jmarsh@microsoft.com>
- Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, <w3c-xsl-wg@w3.org>
Right, I had assumed that he intended to carry on with his assertion that I could not use id(), which clearly wasn't true. If he did intend to switch to tag names (which on second read it seems he did), then your example shows that no multiple parse is needed there either. Basically, there is nothing conceptually wrong with having a parse function. Any XPath implementation must expose a parse method of some kind that returns a node-set in a form that the implementation's eval() function will understand. Exposing that function to the XPath expression author is, then, not such a big leap. Still, it is not a deal-stopper for me if parse() is eliminated. I remain convinced that serialize() is necessary since the whole point of this is to take a subset of the nodes of an input document and output a digestable version of the input - the excluded nodes. John Boyer Software Development Manager PureEdge Solutions, Inc. (formerly UWI.Com) jboyer@PureEdge.com -----Original Message----- From: Jonathan Marsh [mailto:jmarsh@microsoft.com] Sent: Thursday, March 16, 2000 1:12 PM To: 'John Boyer'; James Clark; Martin J. Duerst Cc: IETF/W3C XML-DSig WG; w3c-xsl-wg@w3.org Subject: RE: XSL WG comments on XML Signatures > -----Original Message----- > From: John Boyer [mailto:jboyer@PureEdge.com] > 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,t > rue())/e3|pars > e($input,true())/e4 > > <John> > Parsing 4 times in this case is simply not necessary: > > parse($input,true())/descendant-or-self::node()[id("e1")|id("e > 2")|id("e3")|i > d("e4")] This is not equivalent to James' example. I think the following is, however: parse($input,true())/node()[self::e1 or self::e2 or self:e3 or self::e4] I can't think of a situation right now where multiple parses would be necessary, but some of the cases could get pretty byzantine: a | b//x becomes: parse($input,true())/descendants::node()[(self::a and not(parent::*)) or (self::x and ancestor::b)] Generic XPath implementations will be optimized for the simple case and may perform better. Also, just because parse() need only be called once, doesn't preclude users from calling it more than once, which could be quite costly.
Received on Thursday, 16 March 2000 16:55:53 UTC