xml.dom.minidom: the DOM Level 3 Load and Save API is mostly unimplemented

Every xml.dom.minidom document inherits DocumentLS, and most of it raises NotImplementedError:

>>> doc.load("x")
NotImplementedError: haven't written this yet
>>> doc.loadXML("<a/>")
NotImplementedError: haven't written this yet
>>> doc.abort()
NotImplementedError: haven't figured out what this means yet
>>> minidom.getDOMImplementation().createDOMWriter()
NotImplementedError: the writer interface hasn't been written yet!

Only saveXML(), createDOMBuilder() and createDOMInputSource() work. DocumentLS also defines _get_async() and _set_async(), where the setter should reject asynchronous loading, but they are never made a property, so async_ is a plain class attribute and doc.async_ = True silently succeeds.

The names come from a working draft. The final Recommendation defines LSParser, LSSerializer, LSInput, LSOutput, LSResourceResolver, LSParserFilter and DOMImplementationLS with createLSParser(), createLSSerializer(), createLSInput() and createLSOutput(), and defines no DocumentLS, DOMBuilder, DOMWriter, DOMEntityResolver or DOMInputSource at all.

Nothing of this is documented -- xml.dom.xmlbuilder has no documentation page, and DocumentLS, DOMImplementationLS, DOMBuilderFilter and Options are not in its __all__ -- and there is no successor in the WHATWG DOM Standard, where parsing and serialization are DOMParser and XMLSerializer in the HTML Standard.

So the question is whether to implement the missing parts, deprecate the whole feature, or leave it and document it as unimplemented. See also gh-152142 about DOMBuilderFilter.

Linked PRs

• gh-156735

Start by reviewing xml.dom.minidom.DocumentLS and xml.dom.xmlbuilder, then compare their APIs with the linked DOM Level 3 Load and Save Recommendation. Check gh-156735 and gh-152142 before deciding whether the affected interfaces should be implemented, deprecated, or documented as unimplemented; done requires an agreed direction and corresponding project changes.