OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] help request: incremental XSLT(-ish?) in javascript

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

[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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS