[XML-SIG] Reconsidering the DOM API

Uche Ogbuji uogbuji@fourthought.com
Tue, 27 Jun 2000 14:37:31 -0600


> <mode="pot stirring">

Eh, exactly what sort of "pot" is that?  <g>

[snip]

>  > Attributes:
>  > 	* arguably more Pythonic (=easier to use)
> 
> In your last post you gave the example:
> 
>  > a=b.childNodes[0].attributes["abc"]
>  >
>  > and this looks like Java:
>  >
>  > a=b.getChildNodes()[0].getAttributes()["abc"]
> 
> Why not use the follows notation:
> 
> a=b.get_childNode(0).get_attribute("abc")
> 
> or perhaps the call chain should be reduced by merging methods:
> 
> c = b.get(childNode=0, attribute="abc") 

This is why I asked the question above.  Way psychedelic, dude.

>  > There are no killer arguments here, just different weights applied to
>  > the various features. I don't think that we are going to agree to break
>  > code today. Maybe later we'll see that there are more DOM implementors
>  > than clients and their ease of implementation will take precedence.
> 
> The standard Python interface may end up having to support both access
> approaches (direct and through methods), which will really make the
> interface ugly.  If we had to choose one, which one will allow the
> greater flexiblity?  

That is how things stand now.  4DOM (and PyDOM) support both.

> Benjamin Saller "getValues" idea looks interesting.  Perhaps it is
> time to step back and ask how easy XML could be if the Python
> interface had nothing to do with SAX or DOM.

But there's plenty of (good) effort in that direction already.  It's 
orthogonal to the DOM mapping decision.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +01 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python