Uche Ogbuji writes:

...

You see, this is why reporting such "bugs" early is helpful. I could have told you ages ago that it is a *bad* idea to call cloneNode on a Document object.

Accordin to the DOM Level 2 spec:

"And, cloning Document, DocumentType, Entity, and Notation nodes is implementation dependent."

That's no reason to think its a bad idea to implement it or need it, just that you can't rely on it being supported by an arbitrary DOM implementation.

OK. So what should it mean to clone any of these node types? I can't hardly imagine anything that doesn't run into circular madness. I think the DOM WG refused to specify this for good reason.

...

I do agree that the confused error message is a glitch. Current PyXML CVS gives a more straightforward "sod off" :-)

Not quite; the previous message would have been raised calling cloneNode() on a processing instruction as well. Or calling it with deep=1 on a portion of the tree that contained a processing instruction. That was a real bug, and not an arbitrary limitation.

OK. Glad it's fixed, then.

...

We choose not to allow it. Perfectly legal, and I think this is the right choice.

Honestly, I think we should implement cloneNode() for Document, simply because not doing so seems an unnecessary limitation. It is not for the library to decide what is right for the application.

It's not arbitrary at all. cloneNode is not supposed to alter the ownerDocument: that is for importNode to do. So if you clone a document node, what happens? Do you Create a new document (and thus docType) node and then effectively call importNode on the childNodes? That's the only approach that makes sense to me. Yet it's quite arbitrary and magical. I would rather force people to be clear about what they're doing by manually creating another document and then calling importNode on all the childNodes of the original. So I do not agree that we should support cloneNode for the 4 unspecified node types.

I agree that not supporting it is legal. The exception that is raised is wrong: it should be xml.dom.NotSupportedErr.

There is no stipulation that such an exception should be thrown. The behavior is impl dependent, and I don't see why that doesn't mean the implementation can choose to throw whatever exception it wishes. However, I certainly do not object to a change to throwing xml.dom.NotSupportedErr. I just don't think it's a bug that right now it doesn't.

...

This is the impetus for the Python-in-a-tie effort for Python proper. I do think we'd make a lot more friends if there were a matching PyXML-in-a-tie. It would mean companies would have to

That would be nice to have. First task: improve & integrate all the random piles of tests out there! They should all be run when I type "make check" at the top level, not just a handful.

Yes. Build and test farms would be the main engine of such an effort. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle... 1EA5A2CF4621C386256BBB006F4CEC