Scott Cantor wrote:
>
>> Because we use it in WSS4J we always rely on the backward compatibility.
>> Changing the WSS4J code just to circumvent a problem would cause a major
>> effort to many applications that actually use WSS4J. Before changing
>> WSS4J we shall check if a fix in xmlsec is more appropriate.
>
> If the issue is with how the XML is being serialized, that's your
> responsibility, not xmlsec's. Namespace declarations can't be assumed. You
> need to manage the DOM rigorously and with great attention to detail.
>
> The fact that a lot of code in these Apache projects doesn't is exactly
> why
> we did our own.
>
> -- Scott
>
>
Scott,
I am uncertain about the underlying assumptions here. Please correct me
where I am wrong in what follows.
The problem I have seen involves canonicalization. The c14n processing model
is defined in terms of the XPath data model. As I understand it, the XPath
data model separates the attribute and namespace axes. You can't find the
namespaces on the attribute axis.
Implementations of c14n may be based on XPath, or not. They may accept a
node set as input, or not. When they do accept a node set, whether that node
set is, in fact, a node set returned by XPath or a DOM nodeset, should it
not be treated in a manner which is compatible with the XPath data model?
When I construct a DOM with default configuration using createElementNS, the
elements have an associated prefix, namespace and local name. I assume such
a DOM is a valid representation of an XML document, because when I serialize
such a DOM, I get a valid octet stream. However, such a DOM does not, before
I normalizeDocument, have attribute nodes containing namespace
specifications. It has something, though, because it serializes correctly.
It seems to me that this situation more closely represents the XPath data
model than does the same DOM after normalization, in that namespace nodes
cannot be found by searching the attribute axis. The can, however, be found
by means specific to namespaces: getprefix, getNamespaceURI, getLocalName.
After normalizeDocument, these relationships still pertain.
If, however, I attempt to set the namespace/attribute node specifically,
using, say,
root.setAttribute("xmlns:my", "a:b:d");
things get messy. For example,
Document doc = newDocument();
Element root = (Element) doc.createElementNS("a:b:c", "my:name");
root.setAttribute("xmlns:my", "a:b:b");
doc.appendChild(root);
System.err.println("root ns: "+root.getNamespaceURI());
System.err.println("prefix: "+root.getPrefix());
System.err.println("localname: "+root.getLocalName());
NamedNodeMap map = root.getAttributes();
for ( int i = 0; i < map.getLength(); i++ ) {
Attr attr = (Attr) map.item(i);
System.err.println("attr name: "+attr.getName());
System.err.println("value: "+attr.getValue());
}
serializeTestData(doc, System.err);
System.err.println("");
doc.normalizeDocument();
System.err.println("root ns: "+root.getNamespaceURI());
System.err.println("prefix: "+root.getPrefix());
System.err.println("localname: "+root.getLocalName());
map = root.getAttributes();
for ( int i = 0; i < map.getLength(); i++ ) {
Attr attr = (Attr) map.item(i);
System.err.println("attr name: "+attr.getName());
System.err.println("value: "+attr.getValue());
}
serializeTestData(doc, System.err);
System.err.println("");
gives me:
root ns: a:b:c
prefix: my
localname: name
attr name: xmlns:my
value: a:b:b
<my:name xmlns:my="a:b:c" xmlns:my="a:b:b"/>
root ns: a:b:c
prefix: my
localname: name
attr name: xmlns:my
value: a:b:c
attr name: xmlns:my
value: a:b:b
<my:name xmlns:my="a:b:c" xmlns:my="a:b:b"/>
I'm not sure when this arrangement of the namespace and attribute occurs,
but the ordering may be affected by the order of creation - createElementNS
first, followed by the attribute setup. In any case, I don't know what the
canonicalizer would do with this. Neither do I know which xmlns:my would win
when the stream is read next time.
The situation is artificial, but the getPrefix, getNamespaceURI and
getLocalName values are constant.
Peter
--
View this message in context:
http://www.nabble.com/Undeclared-namespace-prefix-%22ds%22-error-tp19668706p19773709.html
Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
