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/

Received on Monday, 5 June 2000 16:40:43 UTC