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

Re: <xsl-script>

Subject: Re: <xsl-script>
From: James Robertson <jamesr@xxxxxxxxxxxxxx>
Date: Thu, 13 May 1999 09:51:45 +1000
steven ball acn
At 05:48 12/05/1999 , David LeBlanc wrote:

  | 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.)

Now, I'm in favour of a <script> tag. Otherwise, XSLT will be forced
to be everything for everyone. A truly huge beast.

However, doesn't support for an external, cross-platform, language
signal the end for a lightweight XSLT engine?

There will be a variety of XSLT engines, some embedded in browsers,
others not. They will run on every conceivable platform: Windows, Mac,
Unix, etc.

And every one of these would have to link in/reference/dynamically
link an interpreter/compiler/VM for each and every scripting language.

The code for an XSLT engine may be 500k. The code for the various
script engines could be 10meg+.

Does this mean no embedded XSLT systems? No XSLT for PalmPilots?

I just don't see a solution that will give transportability of
code and functionality. And if we can't seamlessly re-use XSLT
scripts, then why don't we just directly code the transforms
in Perl, Omnimark, Python, etc?

I just don't see how it's all meant to work.

Just my $0.02,

James

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@xxxxxxxxxxxxxx

"Beyond the Idea"
 ACN 081 019 623


 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.