[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Incremental XSLT
> 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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|