Altova Mailing List Archives


Re:

From: David LeBlanc <whisper@------------->
To:
Date: 5/11/1999 12:31:00 PM
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

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.