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

Re: C14N: Non-absolutized URIs

From: James Clark <jjc@jclark.com>
Date: Tue, 12 Sep 2000 10:13:10 +0700
Message-ID: <39BD9F46.848A41B2@jclark.com>
To: John Boyer <jboyer@PureEdge.com>
CC: w3c-ietf-xmldsig@w3.org, w3c-xsl-wg@w3.org
John Boyer wrote:

> <john>Right, and as an application of XPath, we are choosing the behavior
> that is most appropriate to our application.  No matter how much the plenary
> wants to force things on dsig, there is nothing they can do to change the
> behavior of a sha-1 hash.  We MUST have a single behavior, therefore we MUST
> </john>

The decision of the plenary at:

  http://www.w3.org/2000/09/xppa

concludes:

  new specifications prepared by W3C Working Groups include statements
  similar to the following:

    This specification does not define an information set
    [or whatever] for XML documents which use relative URIs
    in namespace declarations."

  or

     The scope of this specification includes all well-formed
     XML documents which use only absolute URI references in
     namespace declarations. Documents which use relative
     URI references are out of scope, and not addressed by
     this specification.

   or words to similar effect.

If you follow this, then you would simply say that you spec does not
apply to XML documents including relative namespace declarations, just
as it does not apply to ill-formed XML documents, nor to documents not
conforming to the Namespaces Rec.  If you do this, you don't need to
wait for any XPath errata.

> It is essential that a single behavior be defined for C14N, and the fact
> that XPath permits application-dependent behavior means that applications
> (such as C14N) are permitted to define the most appropriate behavior.

Having C14N define the behaviour of namespace URIs is not inconsistent
with XPath (per the proposed errata), but is most definitely
inconsistent with the XML Plenary decision.

James
Received on Monday, 11 September 2000 23:18:38 GMT

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