Berin Lautenbach <berin <at> wingsofhermes.org> writes: > > Rafael wrote: > > > I have been examining the source code around the 'Transforms' implementation and > > it seems like only ns declarations in the context node(s) are used. That would > > mean that only Constants.SignatureSpecNS is somehow recognized. > > From memory, that's correct.
Hmm, it seems like I have missed the canonicalization step when reading the source code...so my provided interpretation could be totally wrong... ;) But if you think that what I found is correct, don't you think it is some functionality that could be added? > So I think what you need to do is either > use your programatic solution or put the NS definition you are > interested in into the dsig-xpath:XPath node itself. > Sorry, but I don't understand the second alternative. Let me explain the scenario in a very short way: - I have a piece of xml data : <wrapper><foo:hello xmlns:foo="http://www.foo.com">world</foo:hello></wrapper> - Only a part will be signed: <foo:hello xmlns:foo="http://www.foo.com">world</foo:hello> - To "select" that part, we want to use a filter2 xpath 'intersect' with value //foo:hello - before signing, we want to show to the end user the piece of data that he/she is gonna sign - That's why we use a piece of code like the one in my first mail to "go through the Document and select it". Input to that code would be the built Document from above bytes plus 'intersect //foo:hello' (in form of a String[][]) - We get then Exception (prefix must ...) - Our solution forces us to collect all the prefix-ns mappings in a list when building from bytes to Document and use that list to provide every XPath2FilterContainer with extra ns info before adding the latter to the NodeHelperList. As, while performing those steps, we haven't added a ds:Signature yet, we don't have any dsig-xpath:XPath elements (nodes) in the Document. How can we apply your second option? Regards, -R
