Re: XSL with scripting

Subject: Re: XSL with scripting
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Tue, 22 Dec 1998 16:30:59 +0200
Flow Simulation <info@xxxxxxxxxx> wrote:

>Now we have seen the latest XSL draft, and scripting hasn't reappeared.
>
>Since there are obviously strong feelings about this, for and against,
>perhaps we should take a vote and send the result to the W3C as
>on the transformation/formatting issue.
>
>I think this one would be a simple yes/no.   Any takers?


I don't think this is a simple yes/no question. We already "know" a lot of
people would like some sort of scripting support (if my survey is an
indication of anything, for example :-), but which form should it take,
exactly? Consider two extreme cases:

- Allow only JavaScript; no API to the XSL processor beyond specifying XSL
select patterns for the arguments and embedding the return value in the
output document; side effects are forbidden (that is, the XSL processor may
call any JavaScript expression at any time).

- Allowing "plug in" scripting languages; specify an API whereby the script
can query the XSL processor state, and invoke XSL processor actions; side
effects are allowed (there is a well defined order to running the scripts).

Not to mention the multitude of interesting points in between: for example,
adopt the first approach but allow the return value to be re-interpreted by
the XSL processor. This keeps the "stateless" and "any order" features but
allows sneaking interaction between scripts using XSL mechanisms such as
modes. This, BTW, is my favorite choice, but I'm sure other people have
their own.

No, it isn't a simple question at all. A hasty decision the wrong way would
be very hard to recover from. My fear is that implementations such as MS's
<xsl:eval> would become a de-facto standard the W3C organization would be
forced to support - and I'm not at all certain that this construct is the
best choice. IMVHO, the best defense against that would be to formulate the
standard way scripting should be done, and specify it as an optional feature
in the first draft. The problem is that you still need to put 100% of the
design work into it, even if it is just an optional feature...

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread