Re: XSL with scripting

[Guy_Murphy@xxxxxxxxxx]

Hi.

I'm sorry but if the W3C persues the stance of simply ignoring flaming from
the develpment community
then I feel it's probably validated the chief frustration of most of the
flamers.

Under the current spec is it possible to address the original problem that
gave rise to this thread, of producing
alternating rows within a table using the current XSL spec without recourse
to script? I believe the roiginal
problem illustrated well need for flexible evaluation.

We can determine index values of elements in relation to other elements,
from there we need to be able to perform
flexible eveluations upon this index, and upon the result take action. The
problem as it stands is that declaritive
models are very good at filtering data, but tend to be poor at actually
*doing* anything based upon that data, for
this reason, we *have* to be able to move to an imperitive model as needed.

Now you can break the paradigm of XSL and make it a hybrid model, or you
can keep XSL as pure as possible
within the declaritive mould and allow people to move to ECMAScript as
needed.

And if you find a lack of copious amounts of source it's because some of us
are busy meeting schedules
out in the market-place rather than accademic institutions or research
labs. I also don't think provision of
source is a valid reason for exclusion from discussion on the list, and
stating such as a requirement for reply
is a little high-handed IMHO.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 12/23/98 04:47:18 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: XSL with scripting




Oren Ben-Kiki wrote:
>
> Flow Simulation <info@xxxxxxxxxx> wrote:
>
> >Now we have seen the latest XSL draft, and scripting hasn't reappeared.
> >I think this one would be a simple yes/no.
...
> No, it isn't a simple question at all.
Quite so.
Extensibility (whether in the form of scripting or something else) will
get into XSL if and when the XSL WG reaches consensus on a mechanism for
providing extensibility.  Flaming the W3C process may be a lot of fun
but it won't help get extensibility into XSL. The way to help get
extensibility into XSL is to provide useful, constructive input to the
XSL WG that assists it in coming up with a design that it can reach
consensus on. At this stage, the kind of input I would find most useful
would be a representative selection of transformation problems that
can't be solved using the current XSL WD and that one might reasonably
expect to be able to solve with an extensibility mechanism. (If anybody
steps up to this, please supply actual source and result XML documents
so that there's no doubt exactly what the problem is.)
James


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






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