[XML-SIG] Reconsidering the DOM API

[Paul Prescod]

Benjamin Saller wrote:
> 
> ...
>
> I am just trying to encourage solutions with very simplistic usage
> patterns and would like to be able to 'sell' that. When people ask what a
> solution looks like in Java or ColdFusion or PHP I want to be able to
> point to a Python solution that is simpler and uses less code.

I agree, but

 #1. I have no time to write it.

 #2. People here are already nervous about including the DOM because it
isn't stable enough/tested enough for them. If you think you will be
embarrased to put our DOM against Java's DOM, imagine the situation if
we don't put in a DOM at all? At this point there are more nay votes
than yay and without a benevolent dictator it isn't clear what other
mechanism would decide inclusion.

Speaking only for myself, and not for anyone else in the group, I would
welcome a module that did simple XPath processing on top of our DOM. I
would support its introduction in 1.6 if 

 a) it came with a complete test suite that did reasonably full coverage
 b) it was "vanilla XPath" with few or no extensions
 c) it was very little code (i.e. a very small XPath subset)

In order to get the conservatives on our side, we might have to call the
module:

import minidom
import experimental_xpath

experimental_xpath.addSupport( minidom )

dom.xpath( "a/b" )

I'm actually not kidding about going that far if that's what it takes to
convince people that we won't be locked into the API forever.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski