Re: Interactive XML

>> > Picking up on one point in this thread,
>> are you guys happy having ecmascript as the available tool
>> for basic processing?
>>
>> It is dismally inadequate for our needs here, has no one else
>> picked up on this? Any sort of forms processing will surely need
>> more than ecmascript?
>
>Why? Thousands of sites use ECMAScript for forms processing today. Before
>there was a web, forms processing was mostly done in variants of basic
>like Visual Basic and PowerScript. If Basic was powerful enough, why
>wouldn't ECMAScript be?

It depends what you're trying to use XSL for. As a client-side 'style
formatter', ECMAScript is probably fine but I think a much more compelling
use of XSL is as a server-side dynamic generator of HTML pages which are
browser neutral (or more likely, browser sensitive). As part of a server
solution ECMAScript and the current XSL scripting model have a number of
major flaws:

1. ECMAScript has no mechanism for handling errors. Microsoft have added a
proprietary try...catch statement in their JScript engine in IE5 which was
badly needed.

2. There is no mechanism in the scripting model to pass external 'context'
into the embedded script. For example, a server-side formatting stylesheet
would be much more flexible if it could access a 'browser capabilities'
object, for example.

3. This is perhaps more a wish than a flaw: I would really like to be able
use scripts to influence which rules fire in addition to using scripts in
actions.

Denis Hennessy




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