> I am uncertain about the underlying assumptions here. Please correct me > where I am wrong in what follows.
I have to warn you, I'm not a c14n expert, and I know approximately zero about XPath. What I'm knowledgable about are the practical aspects of using a DOM and signing. > 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. No, you're incorrect there. First of all, "valid" isn't a term of art there unless you apply a DTD or schema. The term is "well-formed", and it is the case that unless you add a namespace declaration attribute to the element (or it's in scope above), the XML will not be well formed if you simply output the DOM directly. Now, if you run it through a fix-up in which the serializer "just fixes stuff" like adding missing declarations, then yes, it might come out well-formed. Also, I believe that formally speaking, a DOM itself has no well-formedness property. I could be wrong about that. If it did, then I'm saying that in your example, the DOM isn't. > However, such a DOM does not, before > I normalizeDocument, have attribute nodes containing namespace > specifications. It has something, though, because it serializes correctly. It serializes because any DOM can be serialized. "Correctness" depends on context. > 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. That's true, but the fact is that setting a prefix and namespace URI on an element does NOT imply that the prefix is bound to that namespace. That might be nice, but that's not how it works in a DOM. > If, however, I attempt to set the namespace/attribute node specifically, > using, say, > root.setAttribute("xmlns:my", "a:b:d"); > things get messy. Welcoome to XML. And FWIW, you'd use setAttributeNS. NEVER use DOM1 calls if you're using namespaces. > <my:name xmlns:my="a:b:c" xmlns:my="a:b:b"/> I'm pretty sure that's because of your bug, using a DOM1 call to create that initial attribute. > 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. Neither will because that XML isn't well-formed. It won't parse. Try using setAttributeNS and I think you'll have more luck. -- Scott