[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: ANNOUNCE: Petition to withdraw xsl:script from XSL

Subject: Re: 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
xsl bullet points
"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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.