RE: [xml-dev] Incremental XSLT

["Laurens van den Oever" <lvdoever@sdl.com>]

> There's a question about whether incremental transformation is really 
> worth doing, when re-transforming the entire document is often so fast

> that no-one will notice the difference

That is not what we see. The fastest built-in XSLT processor is MSXML.
That will take seconds to run a transform documents 100s of KBs to
several MBs (of output!). And the output is not an HTML DOM, but an XML
DOM that needs to converted into HTML. That by itself is worth doing
incremental updates. Also if there is a upper size limit of documents
for a tool, people will try to use it with documents that exceed that
limit.

What we would need is one or more consecutive transformations from an
XML DOM to an HTML DOM that will incrementally update when we modify the
XML DOM. Ideally it would only transform what is actually visible in the
browser window and it would skip over anything not locally renderable
(select="count(//*)") and revisit when that information becomes
available.

> (transforming a document of modest size usually takes less than 50ms,
so it's quite possible to do 
> it once per keystroke).

From our experience a keystroke needs to be handled under 15ms or the
application will start to feel sluggish.
Our goal would be to have a 10MB document update under 10ms.

Laurens

Laurens van den Oever | Director of Structured Authoring Solutions | SDL
| (t) +31 (0)70 4452349 | (f) +31 (0)84 8382897 | lvdoever@sdl.com

SDL confidential, all rights reserved. If you are not the intended
recipient of this mail SDL requests and requires that you delete it
without acting upon or copying any of its contents, and we further
request that you advise us.

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: donderdag 16 december 2010 10:41
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Incremental XSLT


> Interesting. I guess I should have said that all browser
*implementations* of XSLT run the transform to completion and don't make
it possible to update the output incrementally by changing the input
incrementally and I shouldn't have claimed anything about *design*.
>
> Which implementations support a reflecting incremental input updates
in the output? Given everything that XSLT lets you do, how can the
contribution of a piece of input to the output be tracked in a practical
way?
>

XSLT 1.0's restriction to a single transformation pass certainly makes 
this kind of thing a lot easier, though experience has definitely shown 
that the restriction is too heavy a price to pay.

There's a question about whether incremental transformation is really 
worth doing, when re-transforming the entire document is often so fast 
that no-one will notice the difference (transforming a document of 
modest size usually takes less than 50ms, so it's quite possible to do 
it once per keystroke). I suspect this is the main reason it hasn't been

done. But it would be nice to be less wasteful of battery-power...

I've been thinking a bit over the last year whether the analysis we do 
for XSLT streamability in XSLT 3.0 is usefully similar to the analysis 
that needs to be done to enable incremental transformation. I think it 
almost certainly is. If a template rule is streamable, then there is a 
guarantee that it only sees/consumes the part of the input tree rooted 
at the node which it matches, so if you know that a subtree of the input

has changed, then you only need to re-apply the template rule for the 
root element of that region. This is only useful, of course, if the 
result of the transformation still exists as a tree (unlikely if it's 
multi-phase) and if you know the relationship of nodes in the result 
tree to the nodes in the source tree from which they derived: but the 
backmapping available in XSLT debuggers is a reasonable existence proof 
that this part is doable.

So I think it can be done, the question is whether there is sufficient 
incentive to do it.

Michael Kay
Saxonica

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php