[XML-SIG] Reconsidering the DOM API

Michael McLay mclay@nist.gov
Tue, 27 Jun 2000 13:48:51 -0400 (EDT)


<mode="pot stirring">

Paul Prescod writes:
 > tpassin@home.com wrote:
 > > 
 > > Jim Fulton continued the attributes thread -
 > > 
 > > I still don't see why anyone is still arguing about whether the DOM rec
 > > makes Python use attributes.  It doesn't.  
 > 
 > Nobody is arguing that. Some people *were* arguing that the DOM rec
 > mandates the use of methods (or, more precisely, that DOM ID + Python
 > IDL mapping = methods). But the DOM IDL is clearly not normative because
 > it doesn't even parse as IDL. So we can put that argument to bed. We
 > need to make the decision on technical and aesthetic merits.
 > 
 > 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") 

 > 	* faster for non-computed attributes
 > 	* slower for computed attributes
 > 	* more like Javascript, VB and COM-like languages (C# :) )
 > 
 > Methods:
 > 	* slower for non-computed attributes
 > 	* faster for computed attributes
 > 	* harder to implement
 > 	* more like Java

The implementation details would favor one choice over another so
perhaps these aren't the appropriate metrics to use in making the
decision.

 > 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?  

A methods based interface provides a level of abstraction that easily
allows for future changes in the underlying implementation.  Direct
attribute access will require the future reimplementation to use
getattr and setattr to hide the implementation details from the API.

If making the interface more Pythonic is a priority then should
keyword arguments be considered?  Python is distinguished from 
most other languges by this feature.  Does some variation on the
following make the Pythonic DOM easier to use?

    c = b.get(childNode=0, attribute="abc") # returns a specific attribute
    c = b.get(childNode=0)		  # returns a dictionary of attributes
    c = b.get(attribute="abc")		  # return all childNodes with
					  # an "abc" attribute
    c = b.set(childNode=0, attribute="abc",value="1.0")


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.

Of course we could have two different modules available in the xml
package:
	  xml.dom_by_attributes 
	  xml.dom_by_methods

</mode="pot stirring">