Subject: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1 From: Eric van der Vlist <vdv@xxxxxxxxxxxx> Date: Thu, 01 Mar 2001 20:29:25 +0100 |
"Clark C. Evans" wrote: > > On Thu, 1 Mar 2001, Eric van der Vlist wrote: > > Your text is so exhaustive that it's difficult to agree with > > all the bullet points ;=) > > Thank you Eric. I think the same comment holds within > the group of primary petitioners. Not everyone agrees > with every point made. It is the 'sum of the points > which is important. Yes, of course ! > > > 1. The XSLT specification clearly states XSLT is not > > > intended as a completely general-purpose XML transformation > > > language. XSLT is a special purpose language and should be > > > maintained as such. Much like structured query language, we > > > think the general purpose languages should embed XSLT, not > > > the other way round. > > > > "Embed" reminds me of embedded SQL C, a widely used and, IMO, very > > broken combination with many limitations that made it almost impossible > > to write object oriented or even structured code and I hope we will > > never see embedded XSLT in this way... > > In '93 I had to personally maintain thousands of lines of > SQL Embedded In C. It was a far better solution than > most at the time, and this served as a stepping stone for > "real" report-writers, etc. Which, as far as my thinking > goes, do infact embeed SQL and have not impeeded the the > portability of SQL. While, I feel report specific constructs > within SQL would have seriously hindered SQL portability. I hope I am not too heavily biased by the RDBMS vendor I was working for at that time, but I remember many constraints such as cursors being considered as static variables that had a huge impact on the programming style that did not exist when you were using the native APIs that where roughly similar to ODBC or JDBC. The basic problem of embedding a language into another is the mixing of instructions with different scopes... To come back to to XSLT embedding XSLT within a general purpose language would be as bad an idea as embedding the general language within XSLT (i.e. xsl:script) and IMHO, the clean way to do it is rather through the usage of the function call (or corresponding feature) of each language. Eric > > And in both cases, the combination "code+xslt" is language > > dependent making it rather weird to say that one would be > > portable when the other is not. > > IMHO, We were only talking about keeping the XSLT portable... ;) > > Clark > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list -- See you in Austin (Knowledge Technologies 2001) http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm ------------------------------------------------------------------------ Eric van der Vlist Dyomedea http://dyomedea.com http://xmlfr.org http://4xt.org http://ducotede.com ------------------------------------------------------------------------ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] ANNOUNCE: Petition to wit, Clark C. Evans | Thread | Re: [xsl] ANNOUNCE: Petition to wit, Clark C. Evans |
Re: [xsl] ANNOUNCE: Petition to wit, Clark C. Evans | Date | Re: [xsl] modular xslt design quest, RSuiter |
Month |