- From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Date: Tue, 21 Apr 2009 18:23:46 +0200
- To: XMLSec WG Public List <public-xmlsec@w3.org>
- Message-ID: <49EDF312.4030007@iaik.tugraz.at>
In short ... below is what should remain of C14n's namespace processing: A namespace node is rendered *irrespective of whether* it is in the node-set, if it has not been ancestrally declared. Similar thought could be applied to xml:lang, xml:space and for xml:base [...] more sophisticated versions applying the combination rules of the join-URI-References function. BR Konrad Konrad Lanz wrote: > Konrad Lanz wrote: > >> ####################################################################### >> >> *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
Received on Tuesday, 21 April 2009 16:24:29 UTC