Re: <xsl-script>

Subject: Re: <xsl-script>
From: Paul Prescod <paul@xxxxxxxxxxx>
Date: Tue, 11 May 1999 16:12:24 -0500
David LeBlanc wrote:
> 
> It seems to me that any extensible language can be made into a convenient
> tree manipulation language via an appropriate function library.

This is just not true. I could be wrong but my feeling is that you do not
have a lot of XSLT experience.

An appropriate function library is a start, but you also need a mechanism
for emulating XSL's polymorphism. A single call to xsl:apply-templates can
invoke a dozen *different* rules depending on the structure of the element
tree and those different rules can be specified through a sophisticated
query language. The Perl or even Python equivalent of the following is not
nearly as elegant.

<xsl:template match="P">
  <paragraph><xsl:apply-templates></paragraph>   
</xsl:template>

<xsl:template match="INS">
  <underline><xsl:apply-templates></underline>
</xsl:template>

<xsl:template match="INS[@author='john']">
  <underline><bold><xsl:apply-templates></bold></underline>
</xsl:template>

<xsl:template match="DEL">
  <strike><xsl:apply-templates></strike>
</xsl:template>

Here's where you can prove me wrong. Show me how this would look in your
favorite programming language with an appropriate function library.

> Postscript seems to have the same problem as other languages, such as
> Pascal, that never got a standard library specified. 

Postscript had a standard library built-in. How else could you draw
pixels? Postscript's built-in library was inadequate because there was
always a way to hack around its limitations -- exactly what we are trying
to avoid in XSL.

> The problem with constraints, as I see it, is that how do you know how and
> where to constrain the language? 

That's the trick of language design. You are advocating that we abandon
language design and merely rely on ad hoc solutions coded in scripting
languages. We could have done that with XML itself also. We could be
sending around Java classes and objects instead of text files. XML and the
web are a rejection of that mode of working.

> Can you foresee all the problems within an
> intended usage domain so that you can be confident that you have not overly
> constrained the language? Given that there is virtually no experience with
> using XSLT, I would say not.

XSLT is based on twenty years of work in transforming structured
documents. As soon as you have a generic markup language you need some way
to transform documents that conform to it. There are literally thousands
of people around the planet who are *expert* at doing these
transformations in scripting languages. My company trains several new ones
every week. I'm writing a hairy transformation in Python right now.

But another part of the system I'm doing was done in XSL. Because it was
just so much easier in a language optimized for transformations...

My rule of thumb is:

easy: use XSL
medium-easy: use Python-extended XSL (not available yet)
hard: use XSL-extended Python (available)

"XSL-extended Python" is basically Python with the sophisticated function
library that we have been discussing.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Diplomatic term: "Emerging Markets"
Translation: Poor countries. The great euphemism of the Asian financial
             meltdown. Investors got much more excited when they thought 
they could invest in up-and-comers than when they heard they could invest 
in the Third World.(Brills Content, Apr. 1999)


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread