Re: [xml-dev] Interactive XSLT [was RE: James Clark: XML versus theWeb]

[Michael Kay <mike@saxonica.com>]

On 02/12/2010 04:53, Peter Hunsberger wrote:
> On Wed, Dec 1, 2010 at 6:19 PM, Michael Kay<mike@saxonica.com>  wrote:
>> What I'm trying to imagine is some kind of way of associating XSLT
>> templates with user interface events so the dialog structure is
>> user-controlled. Of course this raises question about how state is
>> maintained; I don't have any well-formulated thoughts on this.
> This is why I mentioned continuations... Basically, you use a model
> where a call path from the server to the client browser returns back
> to the same spot in the template after the client does a submit. State
> is maintained on the server in a call tree.

Reminds me that in ICL in the 1980s we had a 4GL called 
ApplicationMaster in which the application was written conversationally 
- that is, it called read() when it wanted user input - but was compiled 
to an event-driven inversion so it could run in a transaction processing 
monitor where the actual run-time code checkpointed session state 
automatically when waiting for input, to be restored when the user got 
around to responding. Like continuations, except that the programmer 
doesn't have to know about it. I think that's a great way to implement 
an application that wants to control the dialog structure (and I know 
there's something a bit similar in Cocoon).  I'm not quite sure how well 
it translates to an event-driven dialog structure that's under the 
control of the user. But certainly, the advantage of a language like 
XSLT is that such compilation tricks really should be possible, because 
the state isn't too complicated. Indeed, it ought to be possible to 
compile a single stylesheet into a server-side component and a 
client-side component so the application developer doesn't have to worry 
about the low-level AJAX protocols.

Michael Kay
Saxonica