Scott Cantor wrote:
>> 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.
>
And I know nothing about c14n, DOM or signing, and a little about XPath.
>> 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.
>
Point taken. What I meant was just that the the DOM serializes with the
correct namespaces.
> 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.
>
The serializer associated with JDK 1.6.0 does precisely this. I don't
know whether such behaviour is mandated or discretionary, but it is
entirely reasonable. Without is, what is the point of having a method
createElementNS? It's presence, along with getPrefix, getNamespaceURI
and getLocalName, simply muddies the waters.
And if the serializer can interpret the DOM in such a (to me,
reasonable) way, why can't the canonicalizer?
I can't see that anyone would deliberately rely on the fact that, having
created a namespaced element with createElementNS (including the prefix
in the qualified name), that subsequent canonicalization would _not_
include the namespace attribute. I can, however, see that there might be
code out there that is de facto depending on this behaviour.
> 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.
>
setAttributeNS doesn't work for me following createElementNS. I get
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object in a way which is incorrect with regard to namespaces.
This makes sense, but means that the only way to get the xmlns attribute
expressed is to normalizeDocument(). My feeling is that this reinforces
my point about the expected behaviour of the serializer.
Does it work for you? Maybe I'm doing something wrong.
>> <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
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
