RE: Default transforms

Good point. While the Clark's response [1] to your original email [2] seemed
to state that this is acceptable behaviour (that it was their intent only to
return the node from the id() function call, and none of its children), this
is not in keeping with the text about XPtr Bare Names which states:

        The bare name form of addressing is provided for HTML compatibility.
        ... To provide an analog of the HTML fragment identifier behavior 
        (for resources with XML media types, which may include XML-
        compliant HTML) when the identifier that has been provided in the 
        target resource is syntactically an XML Name 
        http://www.w3.org/TR/xptr#synth-2.1.2

I think this is a problem beyond our own employment of XPtr and an
inconsistency in the XPtr spec itself. I'll forward this on ...

Regardless, with your <keep> proposal, are these element going to populate
the actual XML instances being signed? Are we going back to the omit thing?


[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0166.html
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0165.html


At 02:15 PM 6/5/00 -0700, John Boyer wrote:
 >Hi Joseph,
 >
 >The one point I'd make is that our expectations regarding URI="#E" are not
 >the same as a call to the XPath id("E").  The XPath transform only renders
 >nodes in the indicated node-set.  The id function returns a node-set
 >containing the identified element, but all of its descendants are not in
the
 >node-set.  So if E has the following markup:
 >
 >
 ><elem id="E">I am signed.</elem>
 >
 >We expect URI="#E" to generate the entire line above, but the XPath
 >expression id("E") would only generate:
 >
 ><elem></elem>
 >
 >Under our current design, you'd have to tell the XPath to include all of
the
 >descendants.  This was the source of my angst earlier over the meaning of
 >descendant-or-self::node() because I'd like to say:
 >
 >id("E")/descendant-or-self::node()
 >
 >but this doesn't give me the attributes and namespace declarations, so the
 >result would be:
 >
 ><elem>I am signed.</elem>
 >
 >Furthermore, it appears to be syntactically invalid to put anything after
 >the slash that would give me *all* of the nodes.  Therefore, URI="#E" must
 >be stated as being equal to an XPath transform with the following
 >expression:
 >
 >(//. | //@ | //namespace::*)[count(ancestor-or-self::* | id("E")) ==
 >count(ancestor-or-self::*)]
 >
 >The beginning parenthetic means to consider all nodes in the whole tree in
 >the node-set, and the square-bracketed expression determines whether E is
 >the given element node or any of its ancestors.  Only the element E and its
 >descendants (including namespace and attribute nodes) will pass this test.
 >
 >By the way, we could change the XPath transform to make this a little
 >simpler by adding two expressions, <keep> and <omit>.  The idea would be
 >that any node in the keep set would have itself and all of its descendants
 >(including namespace and attribute nodes) rendered automatically, except
 >nodes in the omit set.  A node in the omit set, and all of its descendants
 >(including namespaces and attributes) would be omitted from rendering,
 >except those in the keep set, and so on.  Naturally, it should be an error
 >if the intersection of the two sets is non-empty (equivalently, if the size
 >of the union is not equal to the sum of the sizes of the two sets).
 >
 >With this paradigm, URI="#E" would be equal to an Xpath transform with
 ><keep>id("E")</keep> as a parameter and no <omit> parameter.
 >
 >Perhaps the chairs should bat this formulation around for a while and talk
 >to the implementers about it because it might make sense to parameterize
 >c14n in the same way.
 >
 >John Boyer
 >Software Development Manager
 >PureEdge Solutions Inc. (formerly UWI.Com)
 >Creating Binding E-Commerce
 >jboyer@PureEdge.com
 >
 >
 >-----Original Message-----
 >From: w3c-ietf-xmldsig-request@w3.org
 >[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
 >Jr.
 >Sent: Monday, June 05, 2000 1:41 PM
 >To: Petteri Stenius
 >Cc: IETF/W3C XML-DSig WG
 >Subject: Re: Default transforms
 >
 >
 >At 11:26 AM 6/5/00 +0300, Petteri Stenius wrote:
 > >Chapter 4.3.3 of [1] reads:
 > >
 > >"[URI] permits identifiers that specify a fragment identifier via a
 > >separating number/pound symbol '#'. (The meaning of the fragment is
 >defined
 > >by the resource's MIME type). XML Signature applications MUST support the
 > >XPointer 'bare name' [Xptr] shortcut after '#' so as to identify IDs
 >within
 > >XML documents. The results are serialized as specified in section
 > >6.6.3:XPath Filtering. For example,"
 > >
 > >
 > >My interpretation of 2.1.1 is that there is *no* default serialization or
 > >canonicalization algorithm. But reading 4.3.3 would suggest that XPath is
 > >used by default.
 >
 >Hi Petteri. There was a time when I advocated "clean-URIs" such that if
 >anything beyond merely dereferencing a URI via its protocol scheme was
 >needed, it had to be explicitly represented in a transform. But there's no
 >such thing as a 'clean-URI' so we support URIs with fragment identifiers.
 >When the dereferenced object is XML, that means it's an XPtr expression. We
 >REQUIRE implementations to support the 'bare name' [1], which is a short
 >hand of the XPath id() function [2].
 >
 >So generally speaking there is no default transforms. BUT, if a fragment
 >identifier is used within a <Reference URI="..."> that identifies an XML
 >resource, that means XPtr processing is done and the results need to be
 >serialized according to 6.6.3 [3]. Note, not all XPtr expressions that
might
 >fit in the URI will be supported by Signature applications.
 >
 >I don't find the fact that people are specifying transforms in the URI to
be
 >very 'clean' but at least it's consistent with the rest of the world (or so
 >I'm told <smile>). That's why we recommend:
 >
 >        Regardless, such fragment identification and addressing
 >        SHOULD be given under Transforms (not as part of the URI)
 >        so that they can be fully identified and specified. For instance,
 >        one could reference a fragment of a document that is encoded
 >        by using the Reference URI to identify the resource, and one
 >        Transform to specify decoding, and a second to specify an
 >        XPath selection.
 >        http://www.w3.org/TR/xmldsig-core/#sec-Reference
 >
 >Is this agreeable to your reading? Should we change the text to make
 >something clearer?
 >
 >[1] http://www.w3.org/TR/xptr#synth-2.1.2
 >[2] http://www.w3.org/TR/xpath#section-Node-Set-Functions
 >[3] http://www.w3.org/TR/xmldsig-core/#sec-XPath
 >
 >_________________________________________________________
 >Joseph Reagle Jr.
 >W3C Policy Analyst                mailto:reagle@w3.org
 >IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
 >

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 5 June 2000 17:38:39 UTC