- From: Joseph Reagle <reagle@w3.org>
- Date: Fri, 22 Nov 2002 11:42:34 -0500
- To: berin@ozemail.com.au, w3c-ietf-xmldsig@w3.org
- Cc: John Boyer <JBoyer@PureEdge.com>
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 11:42:48 UTC