[XML-SIG] Showing off the power of Python for XML processing

Daniel Biddle djad022@uce.ac.uk
Tue, 17 Mar 1998 20:08:36 +0000 (GMT)


Stefane Fermigier wrote:
> Message-ID: <19980317140842.40469@riemann.math.jussieu.fr>
> Date: Tue, 17 Mar 1998 14:08:42 +0100
> From: Stefane Fermigier <fermigie@math.jussieu.fr>
> To: XML-SIG@python.org
> Subject: Re: [XML-SIG]  Showing off the power of Python for XML processing

> > 4) TreeApply
> >
> > One trick that I have found very useful is an apply() style
> > helper function for trees.
> >
> > I have an XMLTreeApply helper function that walks an XML
> > tree applying the supplied function to all the nodes in the tree.
> > It proves particular useful for throwaway lambda functions
> >
> > XMLTreeApply (lamdba x:if x.AtElement("FOO"): print GetDataDescendants())
> 
> Yes, that's cool, but it exposes one of the drawback of Python wrt scheme:
> you can't use instructions in lambda expressions.

True, but this isn't much of a drawback as Python supports first-class
functions, which can be locally defined and deleted after use:

def temp(x): if x.AtElement("FOO"): print GetDataDescendants()
XMLTreeApply(temp)
del temp

(I think you've missed some things out of your example, but I've not tried
to add them.) 

> for node in document.getElementsByTagName('FOO'):
> 	...
> 
> ^-- this one in in the DOM core specs, and I guess the W3C is working on
> an extension of this mecanism.

If it's in the DOM spec, people will probably expect it.

> > 5) Exposing XML from non-XML data sources
> >
> > It is only a matter of time before relational databases and so on natively
> > provide functionality to expose their data as XML. In the mean-time
> > wouldn't it be useful if dbm, glob, pstats and even calendar exposed
> > XML?
> 
> Probably.
> 
Something like a toXML() function method on the objects these packages return?

> One related point: I'm still working on the tranformation engine included
> in my DOM package. I have two options: use XSL (i.e. compile XSL stylesheets
> into Tranformer classes), but I personnally dislike XSL, or invent a new
> transformation language.

What in particular do you dislike about it?

> What do you think ? (I can guess the answer: XSL is a standard, blah, blah,
> but ECMAScript is the standard scripting language of XSL, and there is no
> current implementation of ECMAScript in Python that I'm aware of. So even
> if we can compile basic XSL in Python, we can't cope with embeded JavaScript
> without hand-translation).

Actually the scripting language in XSL is *based* on ECMAScript but with a few
modifications to the scoping rules and an additional bit of syntax to make
measurements slightly neater. A perfect ECMAScript implementation would be
not quite right. (Grr!)

Of course, we should complain loudly until XSL supports Python. B-)

-- 
Daniel Biddle
djad022@uce.ac.uk
author of pyfunge