On 13 Mai, 18:08, "Emanuele D'Arrigo" <man...@gmail.com> wrote: > > I just spent the past hour or so trying to have a better understanding > of how the various DOM-supporting libraries (xml.dom, xml.dom.minidom) > work. I've used etree and lxml successfully before but I wanted to > understand how close I can get to the W3C DOM standards.
You might want to look at pxdom if you want a high level of compliance with W3C DOM standards: http://www.doxdesk.com/software/py/pxdom.html > Ok, I think more or less I got it all. A few questions emerged: > > 1) classes in xml.dom.minidom (i.e. Element) seem to be old style > classes. Is there a good reason they are kept that way or simply > nobody had the time/will to update the library to use new-style > classes? I imagine that no-one bothered to update the code. The built-in modules like minidom do get maintenance, but not much further development. (PyXML, which seemed to accumulate code from 4Suite, possibly contributed code to the standard library, but it doesn't seem to be actively maintained or developed any more.) > 2) for a lightweight implementation xml.dom.minidom comes with a lot > of methods that aren't part of the W3C standards. I'm referring to > toxml, toprettyxml, writxml and the _get_* family. Would it be better > if there was a package offering W3C-faithful classes only, on top of > which convenience and compatibility methods are added by another > package (or two!) through subclassing? Those methods probably don't add that much weight, considering the weight that the W3C facilities already necessitate. I attempted to make a somewhat W3C-compliant implementation with the libxml2dom package (http://pypi.python.org/pypi/libxml2dom), although I felt that providing PyXML-like conveniences (similar to those you describe) was beneficial: some of the W3C APIs for parsing and serialisation are baroque, and although I've tried to implement some of those, too, I feel that it isn't a good use of my time. Paul -- http://mail.python.org/mailman/listinfo/python-list
