[XML-SIG] DOM API

[Paul Prescod]

Mike Olson wrote:
> 
> I see PyDOM as its light weight brother.  It gets all of its speed increase
> from not having to wrap every list in a NodeList, and not having to wrap every
> dict in a NamedNodeMap.  Last I looked it also does not create some of the
> "not so important" nodes such as Attrs.

If those are created lazily then there is no runtime cost if you don't use
them.

> In some cases you may care about the document structure but not care about
> name spaces, or attributes, or elements...  I think if we try to make it any
> more lite weight we will only satisfy 1/2 of us because we will need to start
> dropping "non important" parts of the original document.

Yes, this is what worries me. XML is XML. If you want to have a parser
flag to turn off parts of XML then that's cool but a standard API should
not throw away document content without a flag.

> If you really need
> more speed, then grap SAX or expat and go.  

That's what I was thinking earlier today: if these applications need speed
so much then why are they using a tree API at all? My rule of thumb is:
filter==fast, tree==convenient. That's why I instictively put in sibling
pointers in my "minidom".

> Back to the subject at hand.  I think that PyDOM and 4DOM could have a
> standard interface for applications built on top ie 4XSL.  I think we would
> have to come both ways a little though.  Ex. I think it would be very hard to
> get rid of the idea of a Attr class from 4DOM, while I think we could very
> easily extend the NodeList class to support native python list manipulation.

If you make 4DOM more Pythonish and PyDOM gets closer to DOM conformance
then it seems to me that everybody wins unless some outright
incompatibilities are found.

> This would only be the case if the application is never intended for use over
> an ORB (cannot call __getitem__ over an ORB very easily).
> 
> If we do this though, I don't see that alot will be gained.  You can swap in
> and out DOM implementations when ever you like, but you would not be able to
> use the 4DOM implementation and expect 4XSL to function over an ORB.  

Sorry, I don't get that.

> If
> applications that use the DOM use 4DOMS new "quick" API then the speed will be
> about equivelent to that of PyDOM 

4DOM has a quick API? Or are you saying that the Python-ish extensions
would *be* the quick API? Does 4DOM still require the installation of an
ORB?

Your choice would be down to, do I like Andy better, or Mike...:)

This part I understand. I like Mike. We're talking about Michael Jordan,
right?

Anyhow, the main thing I prefer about PyDOM is not performance but the
fact that my customers don't have to install an ORB to use it.

---

I don't quite follow the last paragraph but I'll take a stab:

 * we could make an API that used Python-ish features without being
incompatible with the DOM. 

 * 4DOM could add the Python-ish features and PyDOM could fix any outright
incompatibilities (e.g. attrs)

 * maybe we could add a few convenience functions to make life easier
(e.g. getText, getChildElements)

 * programs that used some DOM features would be incompatible with PyDOM
because it would have optimized some of them away.

 * programs that used the Python-ish features would not work over an ORB.

Actually, I don't buy that last point (maybe its a straw person). We can
easily make a bridge that adds the Pythonish features to objects on the
other side of an ORB (4DOM, Java, whatever). Of course when you are using
4DOM in the same process space you wouldn't use the bridge.

In summary, I think that unifying the APIs of these libraries is the right
thing to do and will give real benefits.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"The Excursion [Sport Utility Vehicle] is so large that it will come
equipped with adjustable pedals to fit smaller drivers and sensor 
devices that warn the driver when he or she is about to back into a
Toyota or some other object." -- Dallas Morning News