Re: Poll: Relative URIs and Strings in xmlns attributes

I very clearly prefer (1), because it's fully aligned with the
rest of the XML world. If it becomes clear how to handle relative
URIs in namespaces, we can update, with an update of the relevant
URIs so that it's always clear what's intended.

The argument that Canonicalization is URI-unaware doesn't hold,
because it can't be namespace-aware and URI-unaware.

Regards,   Martin.

At 00/09/15 17:12 -0400, Joseph M. Reagle Jr. wrote:
>Before we request Candidate Rec status for Canonical XML there's one issue 
>that I've been trying to understand and come to closure on, and that's the 
>implications of the recent XML Plenary decision on Canonical XML: "to 
>deprecate the use of relative URI references in namespace declarations." 
>[1] What does that mean for the Canonical Form? We've had some discussion 
>on this over this week in this WG [2], some discussion in the XML 
>Coordination Group, and I also briefly discussed this with TimBL. I think 
>the two options we now face are below. Please post your preference -- and 
>optionally reason/rationale -- by end of day Wednesday September 30th. 
>(Those cc:'d are invited to make their choice known in an advisory 
>capacity than can convince others of their position, but in the end I'd 
>like to say, "the XML Signature WG feels $this-way about the issue, while 
>others (agree|disagree)."
>
>CHOICES
>
>1. To state that the canonical form of a document containing a relative 
>URI in a namespace is undefined, and consequently such a document can not 
>be signed. (This includes namespaces like "../foo" as well as "bar"; only 
>documents with namespace declaration using absolute URIs are in scope -- 
>just as only well formed documents are in scope.)
>2. To state that the canonical form is URI unaware. In section 3.1 [4], we 
>already disclaim responsibility for resolving/normalizing other URIs, data 
>types, application semantics, etc. (The reason we made this distinction in 
>the first place is because XPath did. However, an errata of XPath might be 
>issued that would make the resulting the string-value 
>implementation-dependent, but we can't say till we see the errata.) 
>Consequently, not only is the issue of the "relative-URI-in-namespace" out 
>of scope, so is the plenary decision.
>
>ARGUMENTS FOR CHOICE (1)
>
>A. The XML Plenary decision recommends W3C specs say, "This specification 
>does not define an information set [or whatever] for XML documents which 
>use relative URIs in namespace declarations." [1]
>B. In [3] DanC stated that, "if you specify how they work today, we won't 
>be able to make a different specification later." I'm very glad the XML 
>Plenary has come to a decision on this and I want to respect the spirit 
>and intended effect of that decision.
>C. (1) seems to be the common interpretation of the plenary decision to 
>Canonical XML by the folks who were active in the Plenary discussion.
>
>ARGUMENTS FOR CHOICE (2)
>
>A. The XML Plenary decision, "Proposed: to deprecate the use of relative 
>URI references in namespace declarations; that is: to say that while they 
>conform to the Namespace Recommendation of January 1999, later 
>specifications such as DOM, XPath, etc. will define no interpretation for 
>them." However, I'm told that "no interpretation"  is not an argument in 
>favor "literal interpretation" which was specifically opted against.
>B. However, it might permit us to make an argument that we are 
>all-together URI unaware.  (The only reason we know these might be URIs 
>and not strings is because of the XPath namespace-node and because of the 
>syntactic sugar of 'xmlns:'.) Later, if consensus is reached on 
>namespaces/URIs, someone can easily write a URI-canonicalization 
>specification and apply it prior to Canonical XML.
>C. Canonical XML is not in the set of specifications (DOM, XPath, etc.) 
>covered by the Plenary decision, but an application of them which is 
>allowed to do as it pleases. Canonical XML is an application of XPath that 
>uses namespace nodes as we choose as a contribution to a generated 
>hash-value. What we do today won't hinder others in the future.
>D. There are documents out there that use relative URIs and need to be 
>signed. (Is this the case for anyone in the WG?)
>
>
>
>
>
>
>[1] http://www.w3.org/2000/09/xppa.html
>>4.2 Proposal
>>
>>Proposed: to deprecate the use of relative URI references
>>in namespace declarations; that is: to say that while they
>>conform to the Namespace Recommendation of January
>>1999, later specifications such as DOM, XPath, etc. will
>>define no interpretation for them. "
>[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0467.html
>[3] Forwarded Text ----
>>Date: Thu, 14 Sep 2000 15:35:09 -0500
>>From: Dan Connolly <connolly@w3.org>
>>
>> > 2. Our question is related to the question asked of by Clark [2], 
>> since the
>> > XPath errata attempts to [3] implement the plenary decision [4]. Under 
>> XPath
>> > errata [3] "XPath expressions can still be well-defined on a document
>> > containing relative namespace URIs..." [2]  We also felt that there 
>> can be a
>> > Canonical form of such documents. And our interpretation of [3] led us to
>> > believe it is up to xmldsig to decide how to represent it. We recently
>> > decided to treat relative URIs in these instances as a non-absolutized
>> > string in the Canonical form. However, this caused others to feel this
>> > violated the plenary decision
>>
>>Hmm... yes... I might have told you differently in our
>>earlier conversation, but I think that *any* specification
>>of how a relative URI reference in an xml namespace
>>declaration is to be interpreted is in conflict
>>with the plenary decision; if you specify how they
>>work today, we won't be able to make a different
>>specification later. (Meanwhile, we're allowing
>>implementations to do what they like, so the only
>>chance we really have of specifying how they work
>>later is if the market agrees on some way of
>>interpreting them, and we adopt that way.)
>[4] http://www.w3.org/TR/2000/WD-xml-c14n-20000907#Limitations
>For example, in a digital signature application, a document is often 
>retrieved and processed prior to signature generation. The processing 
>SHOULD include the conversion of relative URIs to absolute URIs, thereby 
>mitigating any security risk.
>
>
>__
>Joseph Reagle Jr.
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Wednesday, 20 September 2000 06:58:21 UTC