RE: here() context and comment nodes

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:[email protected]]
Sent: Monday, May 06, 2002 7:55 AM
To: merlin
Cc: [email protected]
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 <[email protected]> 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/[email protected]/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.