> 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
