ACTION-259 Propoal for the C14N spec change wrt. namespace nodes

Konrad Lanz wrote:
> Hi Frederick,
>
> could you please give me some off-line feedback on this before we
> discuss this in the call, please take the time to also consider *B* as
> we might want to do both. Please do not hesitate to mail me if things
> are not entirely clear.
>
> Thanks and here we go:
>
> #######################################################################
>
> *A* Quick fix proposal (easy and really inclusive)
>
>   1. agnostic about whether namespace-nodes have been selected or not
>   2. treats the special purpose
>   3. never rendering namespace-nodes without their owning element
>   4. needed because Namespace nodes are processed independent of L.
>
> Edit http://www.w3.org/TR/xml-c14n11/#ProcessingModel as follows and
> call the spec C14n 1.2:
>
> 1. s|To canonicalize an element including its namespaces, attributes,
> and content, the node-set must actually contain all of the nodes
> corresponding to these parts of the document, not just the element
> node.|To canonicalize an element it does not matter whether namespaces
> or inherited attributes are in the node-set. Only attributes and content
> must actually be in the node-set to be in the output.|
>
> 2. s|Consider a list [L] containing only namespace nodes in the axis and
> in the node-set in lexicographic order (ascending).|Consider the nodes
> of E's namespace axis in lexicographic order (ascending) as list [L].|
>
> 3. s|A namespace node N is ignored if|A namespace node N is ignored if
> it's owning element is not in the node-set or|
>
> 4. s|has a namespace node in the node-set|has an output namespace node|
>
> #######################################################################
>
> *B* An alternative proposal, closer to current spec language
>
> 1. s|Consider a list [L] containing only namespace nodes in the axis and
> in the node-set in lexicographic order (ascending).|Consider the nodes
> of E's namespace axis in lexicographic order (ascending) as list [L].|
>
> 2. Edit the whole Namespace Nodes bullet in
> http://www.w3.org/TR/xml-c14n11/#ProcessingModel
> by replacing it with:
>
>
>   

/Namespace Nodes - To process a namespace node [N] find the first output
ancestor element [A] of the nodes ancestral to element [O] in reverse
document order having an output namespace node [Na] with the same
local name as [N] (i.e. declaring the same prefix) and [A] is in the
node-set (i.e. [Na] has been rendered in an element and not
"esoterically" turned into a text node). If further [N] and [Na] have
the same value, then [N] can be ignored (i.e. there is an output
ancestor whose namespace declaration [Na] declares the namespace).
Otherwise, process the namespace/ [. . . ]

Nevertheless ... *B1* may however be much easier to understand ...


>
> #######################################################################
>
> *B1* A simpler version of B
>
> Some discussion about *B*:
> At a first look *B* seems to be a complex version of the current spec
> language, but if the section is not formulated in that way, but as it
> currently is in C14n and C14n 1.1, it can happen that [Na], despite not
> being in the node-set would be rendered just as well as [N], because
> [Na]'s parent may not have an ancestor in the node-set or it's parent's
> ancestor may also not have a "selected" namespace node.
>
> So a simpler version might be:
>   
/A namespace node is rendered *irrespective of whether* it is in the 
node-set, if it has not been ancestrally declared.


> Note: The latter fact can be derived from a map of stacks. It maps the
> prefix to a stack onto which the namespace is pushed when the namespace
> declaration is rendered and poped when the corresponding closing tag is
> rendered. So if a namespace node is to be processed, the stack is either
> empty (the declaration will be rendered and pushed) or it has a peek
> value that is not equal(the re-declaration will be rendered and pushed)
> or it has a peek value that is equal (the re-declaration is superfluous)/
>
> Similar thought could be applied to xml:lang, xml:space and for xml:base
> push and pop have to be more sophisticated versions applying the
> combination rules of the join-URI-References function.
>
>
> The current functionality of C14n however would only make sense if C14n
> would render to XML 1.1 where the lack of namespace nodes between [Na]'s
> and [N]'s parents (i.e. [A] and [E]) would have caused a namespace
> un-declaration in [A]'s direct successor which is also ancestor to [E].
> In such a situation (using XML 1.1, and reflecting the lack of a
> namespace node by an un-declaration) the current definition of C14n
> would be sound.
>
>
> BR
> Konrad
>
> P.S.: The Sentence I hate the most in C14n is:
>
> "Consider a list [L] containing only namespace nodes in the axis and in
> the node-set in lexicographic order (ascending)".
>
> The examples (cf the bullet: Persistence of omitted namespace
> declarations in descendants)
> http://www.w3.org/TR/xml-c14n.html#Example-DocSubsets suggest that it's
> correct reading is:
>
> * Consider a list [L] containing all namespace nodes in the namespace
> axis or from the node-set in lexicographic order ...
>
> * Consider a list [L] consisting only of namespace nodes containing the
> namespace axis in lexicographic order (ascending).
>
> ...
>
> The more I think about it the more I feel there is the need for an
> erratum here, as it seems that the example
> (http://www.w3.org/TR/xml-c14n.html#Example-DocSubsets) and the spec
> language might be somewhat contradicting. Reality seems to have given
> preference to the example.
>
>
>   


-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
http://jce.iaik.tugraz.at/sic/products/xml_security/

Downlaod certificate chain (including the EuroPKI root certificate):
http://ca.iaik.tugraz.at/capso/certs.jsp