RE: XSL WG comments on XML Signatures

Hi Jonathan (and Alex),

XPath spec appears at http://www.w3.org/TR/xpath

It would appear that you made the same mistake that I first did when I first
read the XPath spec.  In this language theorist's opinion, the spec
should've been written differently so that BNF rule #1 was actually the root
rule of the XPath language (top down design, anyone?).  The authors chose
instead to begin with "One important kind of expression" known as a
LocationPath (see 3rd to last paragraph of section 1).

However, I would not come down too hard on the Xpath authors since I think
they did a good job of describing an expression language that is very useful
due to how well it is generalized.  In particular, contrary to your claim,
XPath is indeed extensible in the way I described in the XPath transform
section.

In Section 1, paragraph 4 of the XPath spec, it is stated that "The primary
syntactic construct in XPath is the expression. An expression matches the
production Expr".

Expr -> OrExpr -> AndExpr -> EqualityExpr -> RelationalExpr ->
AdditiveExpr -> MultiplicativeExpr -> UnaryExpr -> UnionExpr -> PathExpr ->
FilterExpr -> PrimaryExpr -> FunctionCall

Voila! An XPath expression can indeed begin with a function call.  Thus,
beginning with serialize() and parse() is permissible.

As to your assertion that this application is 'odd', it does not seem that
the authors of XPath share your opinion since they have specified the XPath
root language symbol as Expr and not LocationPath.  You are entitled to your
opinion, but here is why I put it together in the way I did:

1) Everything I did in specifying the XPath transform is a kind of extension
that is permitted by the XPath recommendation.  So, for example, I created
the functions parse() and serialize() because the transform needed
additional *function*ality, so rather than just making up whatever I needed,
I specified it in terms of a function library addition, which is permitted
by XPath.

2) In my original design, I did as you suggested by putting the parsed
version of the input as the context node.  However, there were some nagging
little problems where people wanted to start with a fragment of XML, then
transform.  Unfortunately, we don't have XML processors that work on XML
fragments.  So, by making a function parse(), it seemed easy to prepend an
XML declaration (and a byte order mark, if needed) using string functions
available in XPath, then parse the result and use the output node-set in
further location steps.

3) In my original design, I assumed that the output would be automatically
serialized.  Then it occured to me that a similar argument to that above
could be applied to say that perhaps some minor fix-up of the output would
be needed and could be done using XPath's string functions.

So, given that I already felt that the cleanest way, from a specification
standpoint, of adding functionality to XPath was to add functions, I now
also found that I had a use for them.

There are a few additional comments in line below marked by <john></john>,
but hopefully you now see that the current design is works, offers
additional functionality, and is specified in a way that most closely
matches the enhancement methods suggested by XPath.

Thanks,
John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
jboyer@PureEdge.com



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Jonathan Marsh (by
way of "Joseph M. Reagle Jr." <reagle@w3.org>)
Sent: Tuesday, March 14, 2000 11:43 AM
To: IETF/W3C XML-DSig WG
Cc: w3c-xsl-wg@w3.org
Subject: XSL WG comments on XML Signatures


The XSL WG took a look at the http://www.w3.org/TR/xmldsig-core/ draft,
especially at the XPath and XSLT transformation sections, and had some
serious concerns.

The section on XPath Filtering provides a capability that has often been
requested - the ability to take shape a nodeset returned by the XPath query
into an XML result.  We feel the model you provide will be a valuable
contribution.  However, as consituted, the current formulation does not use
XPath in a way consistent with the XPath recommendation.  We recommend a
substantial redesign of this section.

<john>Obviously, this has been refuted.</john>

Notes on particular issues follow.


[6.3.3 XPath Filtering] "The XPath transform output is the result of
applying an XPath expression to an input string."

Conceptually this is odd.  XPaths is designed to be applied to XML
documents, not to strings.  Serious problems arise from this later on.

<john>The string contains an XML document.  If it does not, then functions
can be used to fix it up before passing it to parse()</john>

"The XPath expression appears in a parameter element named XPath."

No examples of this are shown; I assume the syntax is:

  <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
    <XPath>expression/goes/here</XPath>
  </Transform>

<john>Yes, this is consistent with how all parameters are handled, so there
did not seem to be a need for me to put an example when none of the other
sections contain one. The </john>

But the XPath element does not appear to be in the DTD.  An example would be
useful.

<john>True. The editors changed the transforms such that the additional
parameter was needed (the xpath expression used to be the direct content of
the transform), but they have not yet modified the DTD.</john>

"The primary purpose of this transform is to omit information from the input
document that must be allowed to vary after the signature is affixed to the
input document."

Despite this claim, the mechanism uses an XPath to describe the information
that is to be retained, instead of the information that is to be omitted.
Either the mechanism or this description of what is going on should be
adjusted for consistency.

<john>The result of the XPath is indeed the retained material, however, I do
not see any need for a consistency adjustment.  It is absurd to say that the
omitted information will be the result of the XPath expression, since then
it would not be omitted.
The purpose of using XPath is that it has a 'not' function that allows us to
precisely define that which should be omitted from the input document, and
the result of those omissions is what we will retain.
</john>

[6.6.3.1 Evaluation Context Initialization] "A context node, initialized to
null."

Without a context node, the XPath cannot be applied against an XML tree.  We
suggest that an XPath transform parses the document in all cases (not just
when the parse() function is called), and the context node be set to the
root of the parsed XML document.  The context size and position can then be
initialized to 1, consistent with XPointer and XSLT.

<john>It is not necessary to be consisten with XPointer and XSLT.  It is
only necessary that we use XPath in ways permitted by XPath.  I have
previously shown that this is the case, contrary to your claim above</john>

"(Typically, $input is passed directly to parse(), but if $input does not
contain a well-formed XML document, XPath functions such as concat() can be
used before passing the result to parse())."

The need for this functionality is unclear, but seems to be a motivating
factor in XPath abuse throughout this section.  If indeed this need must be
fulfilled, it should be accomplished by a separate mechanism prior to
application of XPath to the parsed (thus guaranteed well-formed) document.

<john>Why should it be fulfilled by a separate mechanism when XPath has
sufficient string functions to do many fix ups.  If more types of fixup are
required, then we could add additional functions to the XPath transform
library.  That is the appropriate way to extend XPath</john>

"An empty set of namespace declarations. (Note: It is possible to address a
node by its qualified name, even though the evaluation context has not been
initialized with a declaration of the namespace. The XPath language provides
the functions namespace-uri() and local-name() for this purpose)."

It appears quite easy in this syntax (being XML) to allow the user to
declare namespaces for use within XPaths.  XSLT and XLink both provide this
capability.  Using namespace-uri() and local-name() hinders readability and
impacts performance significantly.  This workaround should only be used as a
last resort, and even then many feel that this mechanism is too unwieldy.
We strongly recommend that a syntax for passing author-declared namespace
bindnigs to the XPath evaluation context be developed.

<john>This is more work than necessary given that we would then have to
define how to resolve conflicts between the author-specified namespace
declarations versus those appearing in the document</john>

[6.6.3.3 Function Library Additions] "Function: node-set parse (stringInput,
boolean LexOrder)"

This function will not work as intended.  The XPath BNF prevents functions
from being used as a location step - they can only appear within predicates.
Thus parse()/x (which appears to be fundamental to your design) is an
illegal use of a function.  We recommend that the parsed XML be provided to
an XPath processor through the context node instead, with any necessary
parsing controls specified on the XPath element (for example) and applied
prior to XPath execution.

<john>This has been refuted above</john>

"Function:string serialize(node-set); This function converts a node-set into
a string by generating the representative text for each node in the
node-set."

Under what circumstances would the serialize function NOT be called on a
node-set return?  Since it appears that the vast majority (if not the
entirety) of XPath Filtering operations will need to call this function,
this capability should probably be built in instead of requiring the author
to call it explicitly.

<john>This has been refuted above</john>

Are the serialization constraints consistent with canonicalization?  Is it
inappropriate simply to say that the output is canonicalized instead of
defining the exact representation here?

<john>Canonicalization is more work.  If you want to canonicalize, use the
c14n transform</john>

[6.6.3.4 XPath Transform Output] "serialize(parse($input,
"true")/descendant-or-self::node()[
     not(self::SignatureValue and parent::Signature[@id="S1"]) and
     not(self::KeyInfo and parent::Signature[@id="S1"]) and
     not(self::DigestValue and ancestor::*[3 and @id="S1"])]"

If this is the intended usage scenario (omitting descendants), perhaps a
mechanism based on XSLT match patterns (a subset of XPath) should be
pursued.  Combined with an omission semantic instead of a retention
semantic, the above might be simplified to:

  Signature[@id="S1"]/SignatureValue | Signature[@id="S1"]/KeyInfo |
*[3][@id="S1"]//DigestValue

<john>Yes the above is an intended usage scenario.  One should also note
that XSLT transforms may not be retained due to difficulties that will be
harder to resolve than they were in XPath.  So, the suggestion to use
something from XSLT may not be possible.  However, can you explain what the
above expression does?  How exactly is it indicating that we want the whole
document *except for* the SignatureValue in S1, the KeyInfo in S1 and the
DigestValue in S1?

Also, the above looks vaguely like an XPath expression.  Perhaps you just
have a different way of writing the same thing.
</john>

[6.6.4 XSLT Transform] "Identifier:
http://www.w3.org/TR/1999/REC-xslt-19991116"

<john>I don't care for this transform, so issues about it should be taken up
with the editor</john>

Why is this identifier used instead of the XSLT namespace?  All XSLT
stylesheets contain version info already.


"The Transform element contains a single parameter child element called
XSLT, whose content MUST conform to the XSL Transforms [XSLT] language
syntax. The processing rules for the XSLT transform are stated in the XSLT
specification [XSLT]."

This seems quite underspecified after the XPath Filtering section.  For
instance, are similar parsing controls needed?  If not, why are they
necessary in the XPath case?  Are similar serialization constraints needed?
If not, why are they necessary in the XPath case?  Are certain output
methods required (they are optional in XSLT).


[4.3.3.1 The Transforms Element] "<!ELEMENT Transform (#PCDATA)>"

The definition of the "Transform" element is #PCDATA.  This will not allow
an XSLT stylesheet to be included.  The XML Schema defines it as "element
only" but does not define the content.  This definition would not allow a
naked XPath if that is your intent.

In addition, the section mentions that the sequence of transformations can
be XPath, XSLT, or some custom Java algorithm.  It seems rather
underspecified how this sequence of transformations interact (e.g. XSLT
and XPath operate on nodes and the Java operates on ???).

<john>The output of each transform is the input to the next.  There are no
other interactions.  It's all strings of data.</john>

We look forward to working with you to resolve these issues in a way that
meets your needs and is consistent, implementable, and interoperable.

- Jonathan Marsh
  Microsoft

(With contributions from Alex Milowski.)

Received on Tuesday, 14 March 2000 16:12:04 UTC