W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2011

RE: Special cases for PrefixRewrite in C14N 2.0

From: Pratik Datta <pratik.datta@oracle.com>
Date: Wed, 27 Apr 2011 18:44:42 -0700 (PDT)
Message-ID: <3da06821-9236-4f38-913d-d01930692a0b@default>
To: "Cantor, Scott E." <cantor.2@osu.edu>, public-xmlsec@w3.org
I think we should do for disjoint subtrees also.

Let us say some one wants to sign all "CreditCard" elements in the document, then have an xpath like this  //c1:CreditCard

So will each credit card element will be a different disjoint subtree. But should each one get a different prefix?  That will be confusing.

Here is how I would describe it
* prefixes are rewritten to the form "nN", where N is a number that starts from 0 and incremented sequentially. 
* In the canonicalized output for an element, the namespace declaration are output before the attribute declarations. The namespace declarations are sorted by the namespace URI. The attributes are sorted by namespace URI primary sort key and local name secondary sort key.
* A namespace declaration is output only if it is absolutely required.  I.e. it must be visibly utilized and it must not have been output by an ancestor.
* RewrittenPrefixes are numbered in the order they first appear in the canonicalized output. This is not necessarily the order in which the original prefix declaration exists in the document, changes happen due to sorting and visible utilization.
* There is 1-1 mapping between a namespace URI and a rewritten prefix.   I.e. if two different prefixes are defined to the same namespace URI, they are changed to the same reWritternPRefix. Likewise if one prefix is defined to two different namespace URI at different parts of the document, this is changed to two different rewritten prefixes.

-----Original Message-----
From: Cantor, Scott E. [mailto:cantor.2@osu.edu] 
Sent: Wednesday, April 27, 2011 12:01 PM
To: Pratik Datta; public-xmlsec@w3.org
Subject: RE: Special cases for PrefixRewrite in C14N 2.0

> I am thinking that we should change the definition of prefixRewrite so that
> we go by URI and not by prefix.  i.e.  each visibility utilized prefix gets
> mapped to a new prefix, so that there is a 1:1 mapping between URIs and
> new prefixes, but not a 1:1 mapping between original prefixes and new
> prefixes.  With this definition  we would get 1a), 2b and 3b) which I think
> makes more sense.

I would agree, with the caveat that this might only apply within a particular subtree? In other words, if the URI is on the namespace stack, it makes sense to remember the prefix used, but does that make sense if it's been popped off the stack but then appears again in another disjoint subtree?

I guess I would suggest favoring whatever is easiest to describe, and therefore get right. Even if there's some duplication or inefficience.

-- Scott
Received on Thursday, 28 April 2011 01:45:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:15 UTC