Re: <xsl-script>

[David LeBlanc <whisper@xxxxxxxxxxxxx>]

At 04:12 PM 5/11/99 -0500, you wrote:
>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.
>
True, I don't have a lot of XSLT experience - nor do most people i'd guess.
I do have some, what I would call related, experience. 

Based on your below example (even though I think you've shifted the focus
of my issue which is the procedural elements (i.e. <xsl:if> etc.)), I
*might* strike the word "convenient" from the above.

>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.
>
I could think of ways to implement a library in such a way as to allow a
multi-role "firing" upon receipt of an triggering pattern in the input.
Polymorphism is readily found in some (not all) OO programming languages.

><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>
>
THIS is not what I object to! <xsl:if>, <xsl:when> etc. is what I object to!

>Here's where you can prove me wrong. Show me how this would look in your
>favorite programming language with an appropriate function library.
>
That's doable, even elegantly if that's important (A quick sketch in
Smalltalk.):
	myTemplates := XSLTemplateList new.
	myTemplates add:
		XSLTemplate: new;
			'more thought needed here on matching compounds'
			match "INS" && attribute: author with: "John";
			pattern: "<underline><bold></bold></underline>";
			script: ['do something to note I saw John in the input'].
	myTemplates add: 
		XSLTemplate new;
			match: "DEL";
			pattern: "<strike></strike>".
	myTemplates applyTo: someDocument.

>> 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.
>
I suggest people hacked due to inadequacies, not in spite of them, but
that's a petty point. One can hope that XSL won't have any such
inadequacies and that  the designers have the foresight to see all the
usages to which anyone might put XSL - a very tall order imho.

>> 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.
>
No, i'm merely advocating making use of already designed languages for some
parts of XSL in lieu of a newly designed language. There is a thread of
discussion on XML-Dev wrt to passing around java classes and objects -
encoded in a (proposed) XML style notation as a matter of fact. I would
hardly consider XML as a rejection of CORBA.

>> 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.
>
(Excuse me while I digress in a moment of levity: I'd use a razor on that
hairy transformation <grin>.)
I'm a firm believer in structured documents of whatever type. I spend a
good part of every day writing structured docuemnts - they happen to be
called programs, but they are still structured docuemnts and the compiler
(a transformer) is not forgiving when I get something awry.

I have a book around here somewhere on SGML transformations and the several
(many?) specialized scripting languages that have been developed for doing
transformations on SGML documents. I would agree that an open "standard"
for a transformation language is a Good Thing<tm>. (I note that one of
those transformations scripting languages was blinking expensive too - a
common problem of SGML tools.)

>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)
>
Where can XSL-extended Python be found?

>"XSL-extended Python" is basically Python with the sophisticated function
>library that we have been discussing.
>
Errr.. aren't you making my original point here? If XSLT is going to be so
marvelous what need is there for a pythonated xsl (or is it an xslated
python?). Is Python as a scripting language somehow less objectionable then
some other well known language such as pearl or (my favorite) Tcl?

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

As I was responding to this, it occurred to me that you might think I
advocate no XSL at all. That is not the case. I like the notion of
declaring "rules" (templates) which are then processed in parallel against
the input stream. What I object to is the procedural components (if, while,
when etc.) being expressed as notation!.

Sincerely,

Dave LeBlanc

"Pythonation: 1. a large group of hairy pythons. 2. The act of pythonating.
See also: pythonize, pythonate".


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