[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