W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2002

Re: here() function NCName

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>
Message-Id: <200211221142.34280.reagle@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:16 GMT