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

<xsl-script>

Subject: <xsl-script>
From: David LeBlanc <whisper@xxxxxxxxxxxxx>
Date: Tue, 11 May 1999 12:48:21 -0700
xsl script
This is in response to several posts.


Rick Geimer <rick.geimer@xxxxxxx> expressed concerns about maintaining
multiple languages on multiple platforms:

My notion of a <script> tag would include a specification for conforming
languages  including the requirement that such a language be multiplatform.
Imagine the flexibility of being able to use a language you're comfortable
with to do what you need to get done and know that it would be platform
independent too.

I think a reasonable set of requirements for a language that could be used
in a <script> tag would include:
	1. Multiplatform.
	2. Unicode.
	3. Source embeddable.

Languages that *I* know of that are or soon will have such characteristics
are:
	Pearl
	Tcl
	Python
	Javascript
(If your favorite language got left out, I meant no slight - I just don't
know of them, or if they have or will soon have the above chareristics.)

Paul Prescod <paul@xxxxxxxxxxx> discussed tree manipulation specific
languages, Postscript and function libraries, and constraints:

It seems to me that any extensible language can be made into a convenient
tree manipulation language via an appropriate function library.

Postscript seems to have the same problem as other languages, such as
Pascal, that never got a standard library specified. I can't speak to
Postscript, but it was often mentioned that the reason Pascal never caught
on was it's lack of standardized I/O.

The problem with constraints, as I see it, is that how do you know how and
where to constrain the language? 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.

James Clark <jjc@xxxxxxxxxx> mentioned the idea of using nested operations
to extract bits .... shades of lisp and cons(cdr(cons(cdr(cdr)))) (and if
that's correct lisp, it's an accident :-) ).

************************************************

My real compliant about the language embedded in XSLT is that it's ackward,
seems kludgy, offends the eye, reeks of NIH, and mixes up the idea of a
language and a notation. Other then that, it's just wonderful! :-).

I personally think <script> ought to be in XML itself - I can imagine using
it to allow a document to convey (via it's DTD for example) how a receiving
processor is supposed to manipulate it. Very object oriented. Shades of
Active Server Pages even. Conversely, imagine an XSL stylesheet who's
document is a script that knows how to go out and get the data it's
supposed to present - for example a list of stocks one is interested in.
The whole idea of "intelligent content" seems to me to be one of the bright
potentials of the X*L family of notations... if they include a means of
adding "intelligence" to a document.

No offense meant to anyone...

Dave LeBlanc


 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.