On Mon, 2004-09-13 at 20:37, Mikolaj Habryn wrote: > For the benefit of any future searching of the list archives, the > sequence to get this right appears to be: > > a = doc.createElement(localNamespace, prefix + ":" + tag); > a.setAttributeNS(xmlnsNamespace, "xmlns:" + prefix, localNamespace); > a.setAttributeNS(xmlnsNamespace, "xmlns:xsi", xmlschemaNamespace); > a.setAttributeNS(xmlschemaNamespace, "xsi:schemaLocation", > "localNamespace path-to-schema");
...except that it completely fails to work on root elements in a document. Fortunately (for my sanity), it appears that createElementNS *does* appear to work the way that I thought it should. Here's what I see happen. If I create an element with createElementNS(nsX, prefix + ...) and append it to an element which was *also* created with createElementNS(nsX, prefix + ...), the attached element will NOT have an xmlns attribute inserted. That's why we do the 4-line process above, to make sure that xmlns lines do appear, so that c14n works as expected (as per my original plaintive email). Unfortunately, if we do this to the root element, then createElementNS will insert it's own xmlns line due to there being no parent to inherit xmlns from (presumably). If we then create our own, additional, xmlns attribute, everything proceeds correctly, until we dump it out as a string and then try to read it back again, at which point the parser whinges about duplicate xmlns entries. The interesting thing is that if you either a) do createElement(prefix + tag) instead of createElementNS, or b) skip the extra xmlns attribute setting on the root element, it still breaks, just in different places. If (a), then all child elements get a duplicate xmlns attribute, if (b), then it complains that "prefix must resolve to a namespace" during the XMLSignature, somehow ignoring the xmlns attribute that was automatically inserted by the createElementNS (back to the original problem of XMLSignature not seeing namespaces without the 4 line stanza). What am I missing here? There must be something blindingly obvious :( m.
