[XML-SIG] Re: [Twisted-Python] Can anyone recommend a sensible XML parser for Python?
Uche Ogbuji
uche.ogbuji at fourthought.com
Sat Sep 7 12:54:46 MDT 2002
>
> 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
More information about the Twisted-Python
mailing list