Building a DOM from scratch to seraialize requires creating nsPrefix properties on elements and attributes, but also maintaining proper nsURI if you want to use the omit option during serialization.
Might be better to remove nsPrefix from the DOM and instead decide the prefix based on the defined prefixes (favoring the closest ancestor), based on parsing xmlns:foo attributes during serialization.
Positive: fewer moving parts to keep track of, and fixes the bug that allows serialization of invalid documents. When serializing subtrees could even provide the option of generating namespace attributes as necessary.
Negative: would probably no longer round-trip something like this:
<a:foo xmlns="uriA" xmlns:a="uriA"><a:bar /></a:foo>
...because the serializer would see that bar was in uriA namespace and deduce that since its parent element had declared that as a default namespace the output out to be:
<foo xmlns="uriA" xmlns:a="uriA"><bar /></foo>
Building a DOM from scratch to seraialize requires creating
nsPrefixproperties on elements and attributes, but also maintaining propernsURIif you want to use theomitoption during serialization.Might be better to remove
nsPrefixfrom the DOM and instead decide the prefix based on the defined prefixes (favoring the closest ancestor), based on parsingxmlns:fooattributes during serialization.Positive: fewer moving parts to keep track of, and fixes the bug that allows serialization of invalid documents. When serializing subtrees could even provide the option of generating namespace attributes as necessary.
Negative: would probably no longer round-trip something like this:
...because the serializer would see that
barwas inuriAnamespace and deduce that since its parent element had declared that as a default namespace the output out to be: