Re: Interactive XML

Subject: Re: Interactive XML
From: Nigel Hutchison <nwoh@xxxxxxxxxxxxxx>
Date: Tue, 07 Jul 1998 10:48:45 +0200
At 11:33 AM 6/26/98 +0000, you wrote:
>Nigel Hutchison wrote:
>
>> <form action="action" method="method" >
>  [ ... lots of form elements ... ]
>> </form>
>
>I'm not sure what I'm looking at here.  It looks a lot like
>an HTML form.  I can agree that we want, at a minimum, the
>corresponding level of functionality.  

Yes that's it - We have a system that generates itsown XML interfaces and
_one_ of
the user interfaces is a browser. So all we can do right now is map the XML
it to HTML forms.
We chose HTML-similar syntax to make it easy to use for people who know
forms. 
The XML interface is reusable by java programs - for example using the DOM.
The java program
may or may not expose a GUI interface depending on whether a human is in
the loop.

>
>I'm not sure I understand how that functionality is mapped 
>to (some parts of) an XML instance.  Do you mean to represent 
>a set of flow  objects that an XSL engine would render however
>it sees fit? 
No. I mean to represent the interface that the XML application has so that
a stylesheet can
be written to present it to the user as the interface-designer sees fit.
>
>Presumably we'll also want to be able to attach behaviors such
>as "OnClick, OnFocus, etc."  Some of those behaviors would
>be built-in.  Should those that are user defined always be
>expressed in ECMAScript, or through some syntax exposed by XSL?

In our case the system doesn't express the  OnClick, On-Focus  etc - nor
should it in our scenario.
That is added in in the style sheet itself.  Our original system exposed
HTML interfaces and
did supply that level of user interface detail. Now this has been delegated
to the interface builder. 
We can now implement different Browser interfaces exploiting  the same
basic functionality using XSL.
This is what makes XML so cool. The system could store and deliver XSL
stylesheets - but this is an add-on
to its base functionality

But I would like to see a better way of doing this rather that making the
XSL create HTML containing 
OnClick etc.

I think we are talking about two different things.

1. How do XML applications describe and present  their interfaces in XML
format so that style sheets can exploit them.
2. How could XSL express GUI and eventing behaviour in a suitably abstract
way so that XSL processers can render them they it see fit. 

There would be some kind of overlap when the system expresses some kind of
restraint in its XML
interface definition - for instance that the value in a field must  pass a
check expresses as a ECMA script
predicate.

>
>I can see that some of those behaviors will involve rewriting
>parts of the source document grove.  Through the DOM, perhaps?
>
>Just for funsies, I've identified a few potential applications
>for an XSL that supports behaviors.  I think they represent
>some different levels of functionality we may want to consider.
>
>1) a rolodex card editor
>	A UI presents a form for editing the values on a
>        business card. Update, Insert, Delete buttons cause
>	an http message to be sent to server for the appropriate
>	action.
>
>2) a WYSI (almost) WYG docbook document editor
>        Insert, delete text, elements and attributes without
>        having to see the tags.  Constrains editing to enforce
>	validity.
>
>3) A visual XSL style sheet editor.
>        Drag and drop layout components to define our rolodex card
>        editor.  Popup dialogs for editing patterns and actions.
>
>In thinking about these classes of applications, we can start
>to ask some questions about what kinds of abstractions would
>be required, and what types of interactions with the outside
>world would be needed.
>
This would be very nice to have.

regards

Nigel W. O. Hutchison
Technical Consultant
Software AG Germany		                              
mailto:nwoh@xxxxxxxxxxxxxx
           
Tel +49 (0)6151 92 1207                   
                                                                   *


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread