- From: John Boyer <JBoyer@PureEdge.com>
- Date: Tue, 7 May 2002 10:37:50 -0700
- To: "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>, "merlin" <merlin@baltimore.ie>
- Cc: <w3c-ietf-xmldsig@w3.org>
The expectation of comment infestation in the XPath element content was the biggest reason why we defined here() to return the element node parent when it didn't appear in an attribute. Here's the one that originally shook my boots, so to speak: he<!-- Yikes -->re()/blah/blah/blah This is legal XML, so it has to be supported. In general, take the 'string' corresponding to the Xpath element content, which concatenates all text nodes descendants. Thanks, John Boyer -----Original Message----- From: Christian Geuer-Pollmann [mailto:geuer-pollmann@nue.et-inf.uni-siegen.de] Sent: Monday, May 06, 2002 7:55 AM To: merlin Cc: w3c-ietf-xmldsig@w3.org Subject: Re: here() context and comment nodes Right. My question is: does your implementation collect the data from ALL Text nodes to evaluate the XPath? Until now, my implementation crashed if e.g. a PI is inserted into the Text (yes, I know: PIs are not allowed in XML Signature). Christian --On Montag, 6. Mai 2002 15:45 +0100 merlin <merlin@baltimore.ie> wrote: > > here() returns a node set containing either the attribute > node, processing instruction or element holding the > expression; not the text node(s). So here() is { <XPath> }. > > Merlin > > r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.05.06/16:29:43 >> Hi all, >> >> short question about this: Did anyone ever had problems with things like >> this: >> >> <XPath xmlns="&xmldsig-xfilter2;"> >> here()<!-- comment -->/ds:Signature[1] >> </XPath> >> >> I mean that the XPath is "polluted" with a comment which splits the >> String? I figured out that this probably crashes my implementation.
Received on Tuesday, 7 May 2002 13:38:22 UTC