XML

[Alan Kennedy]

"A.M. Kuchling" wrote:

> When you think about it: how useful is it that the Python DOM
> interface uses the same method names as the Java or Perl interface?
> What's gained by this?

Code interoperability. This is very important, given the "glue" like
nature of many uses of python, for scripting COM, Java, .NET, etc. So
I can do things like this (off the top of my head, not tested)

def loadDOM(filename):
    try:
        from win32com.client import Dispatch
        msxml = Dispatch('Msxml2.DOMDocument.4.0')
        domtree = msxml.load(filename)
    except ImportError:
        import xml.dom.minidom
        domtree = xml.dom.minidom.parse(filename)
    return domtree

dom = loadDOM('myfile.xml')
for anchor in dom.getElementsByTagName('a'):
    print "Link: %s" % anchor.getAttribute('href')

> I initially thought there might be some gain from being able to use
> material written for other languages to learn the API, but don't
> know how most users learn the DOM; do they read the DOM Recommendation,
> look at tutorials, read the implementation source, or just copy
> existing code?

I read the DOM Recommendation :-)& But I did all of the others as well,
at different stages, and I think most people end up doing more than one
as well.

> In this context, I find the existence of jDOM, a Java-centric
> DOM-like API, to support this view.  There's even a jDOM JSR,
> the Java world's equivalent of a PEP.

It's a pity that the JDOM isn't very well designed for extensibility,
as opposed to DOM4J, which is so extensible that it has a steep
learning curve. (I actually ended up writing my own minimal read-only
XOM for a Java app, because it was quicker than trying to get JDOM or
DOM4J to do what I needed. I must find the time to open source that
one of these days, with its jaxen adapter).

Which I think illustrates the simple point that many interfaces are
needed in different scenarios: it's "horses for courses". Sometimes
one needs interoperability, as per the 1st example above. Sometimes one
only needs simplicity, so something pythonic like elementree or pyxie
is suitable. Other times, requirements are somewhere in the middle of
those two.

I generally find that interoperability is almost always worth the
pain, if the code is going to be used for any period of time. When use
cases change and, for example, processing volumes increase, or I need
to (schema)validate documents, then interoperable code greatly simplifies
the problem, because I can switch seamlessly to a high-performance DOM,
or one that does validation, or supports 
xpath/relaxng/xpointer/events//whatever.

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/mailto/alan