Re: declarative expressons in WF2

On Mon, 26 Mar 2007, James Graham wrote:

> Dave Raggett wrote:
>> The authoring tool is provided by a third party and includes 
>> support for both client and server side resources, covering a 
>> range of use cases.
>
> So I still don't understand. Myabe you need to point me at an 
> example of the type of tool you have in mind so I can understand 
> how it is expected to work. If our tool is implementing the 
> server-side logic based on some sort of non-script user input, 
> presumably it is generating script to run on the server. Therefore 
> working hard to removing script from the HTML is not, in itself, 
> very useful; it optimizes a tiny part of the overall application.

The editor could be a conventional software package, or it could be 
implemented via the web using browser-based editing of server-side 
resources. The tool would create the HTML and CSS for the new app 
and configure the database to match the data model derived from the 
web page. The server side components would be designed by the tool 
vendor for the use cases the tool covers - see my early email.

If you look at my XForms Transitional cross browser examples you 
will see that one of them demonstrates the feasibility of generating 
the XForms model from the HTML. This could then be used to as input 
to the server-side processing and avoids the need to generate a 
script specific to the new web application that the non-techie user 
is creating. This is one of the advantages of a declarative 
approach, you don't need to authoring the client and server side 
scripts separately and then struggle to keep then in sync.

>> The use of declarative representations allows the authoring tool 
>> to recover the original context when the editor next loads the 
>> document. If the application is largely defined in JavaScript, 
>> the editor won't be able to map that back to something simpler 
>> for the non-techie author.
>
> This all applies to the server-side logic as well. In my vision of 
> how such an application would work, HTML would, indeed, not be the 
> editing format; the editing format would be something convenient 
> for the application authors to save whatever state they need for 
> the particular functions their application provides (something we 
> cannot hope to predict and should not try to cater for). The 
> application would also have a "compile for web" function that 
> would take the application-specific format and generate a 
> combination of client-side and server-side code to implement the 
> application.

Then you've missed the point of open standards. Yes you could define 
a proprietary format, but then the user of that is locked into that 
tool. You've swapped proprietary formats on the PC for proprietary 
formats on the server. Out of the frying pan into the fire as they 
say!

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Monday, 26 March 2007 22:06:17 UTC