Mikolaj Habryn wrote:

On Fri, 2004-10-01 at 23:57, [EMAIL PROTECTED] wrote:


create a DOM tree with only <element> ==> serialize it and re-parseit
so you got ==> <element xmlns="http://uri-a";> DOM tree ==> signit
obtaining
<elemenetxmlns="http://uri-a";><ds:Signature>...</ds:Signature> ==> you
cutthe ds:signature and paste in the original DOM tree
obtainig<element><ds:Signature>...</ds:Signature> ==> and now you try
tocheck it and it fails. Natur�lich (naturally) where
isxmlns="http://uri-a"; attribute it is NOT the same document you
sign.The library will be wrong if it said that the sign was correct.



Again, respectfully, I'm compelled to disagree. I have very little experience with XML or xml-dsig, but this just feels very wrong.

Quoting http://lists.w3.org/Archives/Public/www-dom/2003JanMar/0059.html

"Remember, the DOM does not require that all namespace declaration attributes be present. Thus, there may be implied bindings, which may conflict with explicit ones. The namespace fixup algorithm is about finding and "realizing" those; the namespace lookup algorithm behaves "as if" fixup had been performed."



That's correct, but if you see they are discussing about the B appendix of DOM level3 (http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html). In DOMv2 there is no standard algorithm to fix a DOM tree, xerces provides one but that's all. I don't know if crimson provides one (but I think it doesn't). So the serialize algorithm xerces use is the xerces one(that seems is becoming the standardized one but I think that are little but significant differences) the one that crimson(or other jaxp) uses could be different (as the algorithm was set as standard in DOMv3 not DOMv2) and we are trying to be DOM implementation independent(without too much success but we are improvement).

This implies that the fixup algorithm isn't a hack, it's a way of
correctly representing the implicit and explicit namespaces. What the
library appears to do is only consider the explicit namespace
attributes.

To put it another way, the <element xmlns=blah attr=val/> is not a DOM,
it's a textual representation of one. The DOM is an abstract structure
that has a number of characteristics, including namespaces. Namespaces
are represented by xmlns attributes when serialized, but not necessarily
prior to serialization - but that doesn't mean that they don't exist!



In DOMv2 if they are not in the DOM tree they don't exits, in DOMv3 we can still argue about that.

This line of thought (again, I'm a complete novice at this stuff, so
feel free to shoot me down) is what led me to the serialize/de-serialize
hack, which synchronized the implicit namespaces with the explicit ones.

Your recommended solution seems akin to simulating DOM level 2 (which is
a pre-requisite for xmldsig, isn't it?) using a level 1 interface, in
case that is a useful idea for anyone to understand what I'm trying to
say.

m.



First of all, I think that define all the namespaces binding and prefixes in DOM is a pain, but in DOM2 is necessary. When DOM3 becomes a standard, we can implement the same algorithm to fix it, and it is a real pity that DOMv3 hasn't provide a fixup() method in document so appears all the missing nodes in the node, or to obtain the generated prefix with a Element.getGeneratedPrefix() method or something like this, but as they are not available if we want to give this functionality we must implement ourselves the algorithm.

Anyhow if you want to contribute with a patch that implements the fix up functionality xerces way in the c14n phase, please feel free...

Regards,
Raul
http://r-bg.com




Reply via email to