[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: <xsl-script>
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|