It's probably not the environment Thomas is looking for, but I believe 
that InfoPath works this way. It uses XSLT (along with some extension 
attributes) to define a round-trip mapping between stylesheet and source 
tree. Those source-result bindings allow the processor to redraw part of 
the result without having to run the whole transformation over again. 
Chapter 10 (which I wrote) of Office 2003 XML[1] is basically a 
revserse-engineering of InfoPath's XSLT internals. I don't recall if I 
covered this optimization in the book, but I seem to recall reading 
about it.

Here's a quote I found just now: "To avoid running the entire XSLT 
transformation every time the end user enters data in a view or clicks a 
formatting control for rich text, algorithms are used to determine which 
portion of the view needs to be refreshed. Then only the relevant 
portion of the XSLT stylesheet is applied to the DOM, and the affected 
portion of the view is refreshed."[2]

Evan Lenz
http://lenzconsulting.com

[1] http://books.google.com/books?id=xYEyK_7TWP8C&pg=PA426
[2] http://msdn.microsoft.com/en-us/library/bb608310(office.11).aspx


Michael Kay wrote:
>> I want a second DOM around - an XML object.   The HTML
>> DOM for the page is related to the XML object either 
>> literally by an XSLT script or by something similar.
>> When I change the *XML DOM* - I want the HTML transformed DOM 
>> to be incrementally updated.
>>
>>     
> ...
>   
>> I am looking for a way so that if the Javascript program 
>> modifies the XML - say by adding an additional book - that 
>> the HTML DOM is automagically updated, say by inserting a new 
>> "li" element in the appropriate place.
>>
>>     
>
> Incremental transformation - only changing those parts of the output that
> are affected by a change to the input - was one of the potential benefits
> touted when XSLT was designed, and was said to be possible because of the
> declarative nature of XSLT. In practice, it hasn't been delivered. I'm sure
> it can be done in principle, as demonstrated by the "back-mapping" done by
> debugging tools, which link elements in the output to the elements in the
> input from which they were derived. But there's not much investment going
> into client-side XSLT, which might have something to do with the fact that
> it's rather hard to make a business case for such investment.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay 
>   


_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php