W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: AW: Poll: Relative URIs and Strings in xmlns attributes

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Thu, 21 Sep 2000 14:44:32 -0400
Message-Id: <4.3.2.7.2.20000921144056.00baed20@rpcp.mit.edu>
To: "Gregor Karlinger" <gregor.karlinger@iaik.at>
Cc: "Mark Bartel" <mbartel@thistle.ca>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 10:35 9/21/2000 +0200, Gregor Karlinger wrote:
>Hi Mark,
>
>The description of the first choice Joseph has given starts with:
>
> >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. [...]
>
>My way of thinking is that an algorithm performing Canonical XML must return
>an error if it dedects relative URIs in the input. Maybe I am wrong, Joseph?

Excerpting from a member only version of the XML Plenary report:

>Q6:What does the DOM spec return for the namespaceURI attribute?
>A6: Unspecified; out of scope for this version of DOM.
>Q7:what's the value of the XPath namespace-uri() function with <aDoc> as 
>the current node?
>A7: Unspecified. The 16 November 1999 XPath specification progressed to 
>Recommendation with the understanding that multiple interoperable 
>implementations implemented it as specified, or would soon implement it as 
>specified. As it turns out, we have no evidence that multiple interoperable 
>implementations implement the namespace-uri() function as specified.

Again, I'm not exactly sure what unspecified means (saying an error is 
thrown is more specific than permitting applications to do as they wish as 
Mark points out) but the end result is less interoperability for the 
canonical spec, and regardless of the nuances of this issue, that's what I 
think the big goal should be.




__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Thursday, 21 September 2000 14:44:38 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT