Subject: Re: <xsl-script> From: David LeBlanc <whisper@xxxxxxxxxxxxx> Date: Tue, 11 May 1999 19:30:40 -0700 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: <xsl-script>, Rick Geimer | Thread | RE: <xsl-script>, Jonathan Borden |
RE: OO and scripting, Jonathan Borden | Date | Re: <xsl-script>, David LeBlanc |
Month |