[FWD: Comment for XML Signature Syntax and Processing Version 1.1 Working Draft 18 October 2012 (re: here() function)]

I'm resending this, as plain text, because the Web archive doesn't seem
to have stored the message properly...

-------- Original Message --------
Subject: Fwd: Comment for XML Signature Syntax and Processing Version
1.1 Working Draft 18 October 2012 (re: here() function)
From: <edsimon@xmlsec.com>
Date: Fri, November 02, 2012 12:01 pm
To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>,
public-xmlsec@w3.org

G. Ken Holman of Crane Softwrights (copied) has noticed an issue 
(detailed below in Ken's email) with the definition of the here()
function in XML Signature. After Ken brought this to my attention, I
have been wondering if the namespace injection/wrapping issue [1] [2]
that Meiko and I investigated might be applicable to this issue (and
thus make it more important than just a "function not found" problem).


Ed

[1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Dec/0000.html

[2] http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/0005.html

  -------- Original Message --------
 Subject: Comment for XML Signature Syntax and Processing Version 1.1 
 Working Draft 18 October 2012
 From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
 Date: Wed, October 31, 2012 7:00 pm
 To: <edsimon@xmlsec.com>
 ...
 
 Attn: Editors of XML Signature Syntax and Processing Version 1.1
 Re: Working Draft 18 October 2012
 
 Since version 1 of XML Signature there has been a glaring (to me) 
 error in the specification of the "here()" function, in that it was 
 never properly named using a namespace qualification.
 
 Languages that use XPath typically assume that unprefixed function 
 names are functions in the XPath library and that functions outside 
 of the XPath library must be prefixed with a namespace qualification 
 of some kind. Certainly XSLT and XQuery impose this 
 constraint. Indirectly so does Schematron. Such a constraint has 
 not been a part of XMLSec.
 
 The (low probability) issue is that who knows what future versions of 
 XPath might include in a function named "here" of its own? It would 
 be unavailable to users of XMLSec (or, worse, implement some 
 unexpected future semantic).
 
 The (guaranteed probability) issue is that a general-purpose XPath 
 analyzer looking at the expression would flag the "here()" as a 
 syntax error because the unprefixed function is not part of the 
 standard library.
 
 Standalone XPath processors may soon be available. Implementers of 
 XMLSec who want to use such a processor are going to be challenged 
 since the expression will trigger "function not found" errors when
analyzed.
 
 But I acknowledge that there is already an established base of using 
 "here()" with XML Signature 1.0.
 
 My thought is that "here()" could continue to be allowed for backward 
 compatibility, but would be deprecated from now on in favour of 
 something like "ds:here()" (where, of course, the prefix is 
 irrelevant but it is mapped to the signature namespace).
 
 Then, a general-purpose XPath processor would look for the function 
 named "{http://www.w3.org/2000/09/xmldsig#}here()" in the set of 
 statically-defined function signatures provided by the application 
 invoking the XPath processor:
 
 http://www.w3.org/TR/2007/REC-xpath20-20070123/#static_context
 [Definition: The static context of an expression is the information
 that is available during static analysis of the expression, prior to
 its evaluation.] This information can be used to decide whether the
 expression contains a static error. If analysis of an expression
 relies on some component of the static context that has not been
 assigned a value, a static error is raised [err:XPST0001].
 
 http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-function-signature
 [Definition: Function signatures. This component defines the set of
 functions that are available to be called from within an expression.
 Each function is uniquely identified by its expanded QName and its
 arity (number of parameters).] In addition to the name and arity,
 each function signature specifies the static types of the function
 parameters and result.
 
 http://www.w3.org/TR/2007/REC-xpath20-20070123/#id-function-calls
 [Definition: The built-in functions supported by XPath are defined in
 [XQuery 1.0 and XPath 2.0 Functions and Operators].] Additional
 functions may be provided in the static context. XPath per se does
 not provide a way to declare functions, but a host language may
 provide such a mechanism.
 ...
 A function call consists of a QName followed by a parenthesized list
 of zero or more expressions, called arguments. If the QName in the
 function call has no namespace prefix, it is considered to be in the
 default function namespace.
 
 http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-def-fn-ns
 [Definition: Default function namespace. This is a namespace URI or
 "none". The namespace URI, if present, is used for any unprefixed
 QName appearing in a position where a function name is expected.]
 
 Having the function name namespace qualified would allow the 
 expression to be rewritten in an XPath context without having first 
 to inspect the expression for the errant (to the XPath processor) 
 "{}here()" syntax. As it stands today, there is a burden on 
 implementation to prevent the "{}here()" function from getting to an 
 XPath library written as it is for fear of triggering a static error 
 "err:XPST0001".
 
 I hope this is helpful.
 
 G. Ken Holman
 gkholman@CraneSoftwrights.com
 http://www.CraneSoftwrights.com/bio
 
 --
 Contact us for world-wide XML consulting and instructor-led training
 Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/
 G. Ken Holman mailto:gkholman@CraneSoftwrights.com
 Google+ profile: https://plus.google.com/116832879756988317389/about
 Legal business disclaimers: http://www.CraneSoftwrights.com/legal

Received on Friday, 2 November 2012 16:07:18 UTC