[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: <xsl-script>

Subject: Re: <xsl-script>
From: David LeBlanc <whisper@xxxxxxxxxxxxx>
Date: Tue, 11 May 1999 19:30:40 -0700
xslt underline
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 match="INS">
>  <underline><xsl:apply-templates></underline>
><xsl:template match="INS[@author='john']">
>  <underline><bold><xsl:apply-templates></bold></underline>
><xsl:template match="DEL">
>  <strike><xsl:apply-templates></strike>
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
	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!.


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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.