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

This closes  ACTION-260
Pratik

Pratik Datta wrote:
> We should not do any kind of small modifications.
>
> The cost of code changes is very minuscule, compared to cost of 
> uptaking this change in all the upper level layers - (WS Securty, 
> SAML, ebXML etc).
> So we need to step back and think about it for some time, and see the 
> big picture, and try to solve all the problems in one revision,  XML 
> Signature is already well solidified, and we will get at most one 
> chance to change things.
>
> About this particular issue - why does XML Signature have to deal with 
> "Namespace Nodes" at all?  Namespace nodes is not an XML concept. It 
> is just an artifact inherited from XPath.
>
> What we basically need is way to sign a subset of the XML document, 
> and XML Sig 1.0 used the XPath nodeset as a means to represent this 
> subset. But that is not the only way to represent a subset.
>
> As I mentioned in call, I want to give an algorithm to canonicalize a 
> single complete subtree.  This would do exactly the same thing, but 
> can be expressed in far more simpler terms.
>
> Pratik
>
> Konrad Lanz wrote:
>> I pasted the wrong version, which enabled to remove namespace context by
>> XPath expression, so here is an update ...
>>
>> Sorry should not work that long ...
>> BR
>> Konrad
>>
>>
>> Konrad Lanz schrieb:
>>   
>>> 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] and [Na] are
>>> both in the node-set (i.e. [Na] is 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/ [. . . ]
>>>   
>>>     
>>
>> This obviously has to be formulated like this, otherwise it will suffer
>> the same problem as before:
>>
>> /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
>>> [...]
>>>   
>>>     
>> /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.
>>>   
>>>     
>>
>>   
>