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


Reply via email to