Re: Difference between XSLT and (s)XBL?

Cyril,
We had long discussions in the SVG working group about the relationship of 
XSLT and XBL and concluded that they are very different things.

XSLT defines the transformation of Infoset A (which might be multiple 
different files) into Infoset B (which might be multiple different files). 
It is an irreversible/one-way batch process. There is no defined 
interactive event model. Of course, XSLT could be extended to support lots 
of different things, but I would argue that it does a very nice job today 
addressing XML-to-XML transformation requirements and it should stay 
focused as an orthogonal component on just that one problem.

XBL, on the other hand, really isn't about infoset transformations. The key 
thing with XBL is its processing model around attaching a shadow tree to an 
element such that the shadow tree gets formatted and rendered instead of 
the original element. XBL's built-in "transformation" facilities for 
building the shadow tree are very primitive - just an optional cloning 
operation and a couple of events which get fired along the way (xbl:prebind 
and xbl:bound). In general, today with sXBL, the "transformation" part of 
XBL is done mostly with scripting.

Because XSLT and XBL are different things, you would think that they could 
be used together, and, in fact, they work very nicely together. Adobe 
implemented a prototype of some code which does both XSLT and XBL together, 
where you could run an XSLT transform on the <xbl:template> sometime around 
the time the 'xbl:prebind' event is fired. If XSLT and XBL were both 
available, then the XSLT transformation conceptually becomes be a 
replacement operation for current XBL cloning operation on the 
<xbl:template>. If XSLT and XBL were both available, you can look at the 
clone operation as the default XSLT transformation if an XSLT 
transformation isn't specified.

The SVG working group decided *against* requiring XSLT in SVG 1.2/sXBL. We 
had our hands full with the things already on our plate. But maybe XSLT 
will become a requirement part of a future version of SVG (e.g., 1.3).

Jon Ferraiolo
Adobe Systems, Inc.
sXBL co-editor

At 05:37 AM 9/21/2004, Cyril Concolato wrote:

>Dear Scalable Vector Graphics Working Group,
>
>I have started reading carefully the sXBL working draft and also the 
>different threads on this mailing list and I would like to hear more about 
>the difference between (s)XBL and XSLT. I understood that one difference 
>resides in the event handling:
>
>Chris Lilley wrote
>"... its important to note a big difference between
>XSLT and sXBL. In XSLT, its a one-shot, batch-like transform. If any
>changes are made to the result, they have no effect on the source and do
>not cause the transform to re-run;..."
>This is a behaviour of the current XSLT processors. One could imagine a 
>different XSLT processor that could re-run the transform. (s)XBL could 
>define a different way of processing the XSLT templates. This would avoid 
>having two W3C standards doing very similar things.
>
>"... Its certainly possible to imagine a continuously looping XSLT
>process triggered by mutation events (at least, for source changes) but
>its hard to iimagine event flow in the result tree continuing
>uniinterrupted in that case."
>Probably because I am new to XML events, I don't understand this 
>statement. Why wouldn't it be possible to have such a model working on 
>XSLT templates while it is working with sXBL templates ? Could you give an 
>example?
>
>Best regards,
>
>--
>Cyril Concolato
>Dept. Comelec
>Ecole Nationale Supérieure des Télécommunications, Paris
>46, rue Barrault 75013 Paris
>Tel: +33145817991    Fax: +33145804036

Received on Saturday, 25 September 2004 00:20:41 UTC