Re: here() function NCName

Joseph,

You are quite correct - my issue at the moment is purely an 
implementation issue and easily solveable.  I raised it more from the 
perspective that it may cause issues in the future.

The only time that I can see where it might cause an interop problem is 
if there is another here function defined in the app unlikely?).  They 
way around might be to use the XML Signature prefix defined in the doc 
e.g. (for a Enveloped Signature)

count(ancestor-or-self::dsig:Signature |
dsig:here()/ancestor::dsig:Signature[1]) >
count(ancestor-or-self::dsig:Signature)

which would work in my implementation but might break others.

Maybe something to sort out later once XPath 2.0 is finalised.  That 
might drive the issue.

Cheers,
     Berin


Joseph Reagle wrote:

>On Monday 18 November 2002 09:22 pm, berin@ozemail.com.au wrote:
>  
>
>>One thing of interest has just come up around XPath and the here()
>>function.  In particular the XPath implementation is used as a basis for
>>XSLT and only allows External functions (such as here()) to be installed
>>if they are namespace qualified.  Which means that it won't process the
>>here() function when it is presented as an NCName.
>>    
>>
>
>Hi Berin, I haven't encountered this issue before. You are right that the 
>function is a QName:
>  http://www.w3.org/TR/xpath#NT-FunctionName
>  [35]   FunctionName   ::=  QName - NodeType 
>  http://www.w3.org/TR/REC-xml-names/#ns-qualnames
>  [6] QName ::=  (Prefix ':')? LocalPart
>
>  
>
>>Given their are at least two definitions of here() (Signature and
>>XPointer - both currently with the same semantics) should XML Signature
>>define the here function as part of the DSIG namespace?
>>    
>>
>
>At this point, I'm not sure how we would do that, but since the semantics 
>with XPtr are the same -- something we coordinated on -- does your 
>implementation also require the xptr:here()?  In the future, I think this 
>is something folks should be cognizant of, but it's not causing an interop 
>problem presently is it?
>
>
>  
>

Received on Friday, 22 November 2002 15:52:19 UTC