This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
- From: Eric van der Vlist <vdv at dyomedea dot com>
- Date: Thu, 01 Mar 2001 20:29:25 +0100
- Organization: Dyomedea <http://dyomedea.com>
- References: <Pine.LNX.4.21.0103011351370.23946-100000@clarkevans.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
"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