[XML-SIG] Pyxie

[Paul Prescod]

Ken MacLeod wrote:
> 
> The parsers on the Pyx site are expat and rxp ('xmln' and 'xmlv';
> non-validating and validating, respectively), so they are fast and
> small.

But you have to run them in a different process and use pipes and
"double parsing." For a long time I couldn't understand why you would
choose to do that and then I realized that the real reason is to allow
Pyxie to use a pull model rather than a push model of parsing.

But Fredrick has shown that you can do pull parsing without a separate
executable so I don't really see the benefit in pyx anymore. If you want
a simplified XML interchange format, you might as well use canonical
XML:

http://www.w3.org/TR/xml-c14n

<minirant>
The problem with comparing the various APIs that are popping up is that
the proponents of one view or the other are not typically very
knowledgable about the other's approach. Consequently, I haven't heard
clear descriptions of why the Pyxie approach is better. i.e. I would
like to see some ugly DOM code transformed into beautiful Pyxie code. I
would like to be convinced that these advantages are somehow inherently
tied to the fact that Pyxie uses its own tree data structure rather than
the DOM and its own event model rather than SAX. If Pyxie's features can
be added to established APIs then that's the better way to go.

In my opinion, it is mostly a difference in philosophy. I presume that
APIs like SAX and DOM are fundamentally fine and just need a few good
ideas added to them. I think that the "cross-language" versus "Pythonic"
dichotomy is a false one. Pyxie would be a great Java API. DOM is also a
great Python API. Languages are not *that different*. You tweak the API
a little to make it "at home" and they typically work just as well in
one language as in another.

What is it that Pyxie really does that is cool? From my perusal, it is
pull parsing and the event/tree hybrid. Based on inspiration from Pyxie
I've added these features to the DOM through pulldom. I'm not as sure
about the cut and paste model of tree modification -- I don't typically
write tree-mutating applications.

The same holds for the other new API proposed this week. It adds a good
idea (XPath addressing) to a tree data structure but invents a whole new
tree data structure rather than using the DOM! There's no need to do
that.

I do not personally feel that basing our APIs on SAX and DOM requires
any compromises in terms of "Pythonicity." As we have been discussing
this week, I am in favor of using every last feature of Python
(including __getattr__, __getitem__, etc.). I don't see why using those
features should require abandoning the core of established, popular APIs
like DOM and SAX.
</minirant>
-- 
 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