Re: Filter2 transforms fails when xpath-values contains prefix

[[EMAIL PROTECTED]]

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
 

Well,
I have found where the problem is:
In the CachedXPathFuncHereApi.eval() {
      ...
     // Create an object to resolve namespace prefixes.
     // XPath namespaces are resolved from the input context node's 
document element
     // if it is a root node, or else the current context node (for 
lack of a better
     // resolution space, given the simplicity of this sample code).
     PrefixResolverDefault prefixResolver =
        new PrefixResolverDefault((namespaceNode.getNodeType()
                                   == Node.DOCUMENT_NODE)
                                  ? ((Document) namespaceNode)
                                     .getDocumentElement()
                                  : namespaceNode);
      ...
}
The PrefixResolverDefault only resolves prefixes defined in the 
namespaceNode.

In the transformXpath2 the namespaceNode is the same xpathContainer 
element (i.e. the signature) so it only resolve namespaces defined in 
this element, one change I have tried is to change this to the document 
node. With this change your example pass if you modified the document from
<Document > to <Document  xmlns:bla="">

But it isn't very smart, then what's the good solution? Required that 
the signed element(or the document after patch) defines all the elements 
or do a recursive PrefixResolver?

If the latter, how to cope with definitions like this
<doc>
<a:b a="uri3"/>
<a:a a="uri1">
 <a:ToBeSigned a="uri2"/>
</a>
</doc>
what's the value of the prefix a?
All in All it seems is easier if you put all namespace definitions you 
need in the signature element.

Regards,
Raul