[XML-SIG] getDOMImplementation() extension

[Fred L. Drake, Jr.]

I've just checked in an extension to the getDOMImplementation()
function provided by the xml.dom package.  The extension is that the
"features" argument can now accept a string that lists the features
that are being requested as well as a sequence of pairs; the syntax of
the string is brain-dead simple (modulo a lack of precision in the DOM
Level 3 drafts, which I'll address to the DOM comments if I haven't
already).

Background:

Martin added the xml.dom.domreg module and the getDOMImplementation()
function in Feb 2001, before the DOM working group came up with the
"DOMImplementationSource" interface and its only method,
getDOMImplementation().  The functionality, however, is essentially
identical, though there were minor differences in the signature.  The
changes I checked in allows the arguments to match either the original
Python definition for the function or the W3C definition.

Issue:

There is an issue with this addition, however, though I don't think
it's a major one.  The draft Level 3 specification states that the
getDOMImplementation() function should return null (None in Python) if
there is no suitable implementation, whereas the
getDOMImplementation() function we already had raises ImportError
(weird, but that's how it is).

Now, part of this comes from my desire not to have two functions/
methods with slightly different behaviors but identical functionality;
we *could* say that the xml.dom package is not an implementation of
the DOMImplementationSource interface, and provide a separate object
that does that, if we think we need one.  That feels pretty
distasteful to me, since the interface we have is reasonable.

Proposal:

Though it's possible to use the type of the value of the "features"
argument to determine whether to return None or raise an exception,
that seems both fragile and rediculous.  I'm going to propose that we
simply declare (via documentation) that the Python binding for
getDOMImplementation() raises ImportError instead of returning None.
I wanted to bring the issue up here before doing that since that
doesn't fall into the same pattern as the rest of the binding and does
diverge from the W3C specification (however draft it may be).

Comments?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation