People have been wanting to meld WYSIWYG and XSLT for a long time, and keep running into that same set of challenges. Given the way XSLT works, where any portion of the output may be dependent upon any portion of the input (including exact text content), incremental re-rendering is emphatically nontrivial and general WYSIWYG is probably not a good idea. The canonical examples would where entering one character trips a conditional and causes an entire section of the document to no longer be included in the output -- making it impossible to change back in a WYSIWYG manner --- or where a displayed result could be produced multiple ways, so it's impossible to determine what should be done to the source document based only on changes to what-you-got. WYSIWYG really is the wrong way to think about working with XSLT
Having said that, incremental rendering might be interesting even in the non-WYSIWYG mode (type in one window, display test rendering in another). However, the additional bookkeeping to make that work would be nontrivial, as just discussed -- you wind up with (ahem) interesting dependency graphs. I think that's been looked at several times, but I haven't heard of anyone releasing a robust version of it. If you find one, please let us know; I'd be interested in looking at how it works. Sorry I don't have a more helpful answer... ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)
