[XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?

[Uche Ogbuji]

> 
> 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/8A
1EA5A2CF4621C386256BBB006F4CEC