Re: Fw: XForms requirements

I thought I'd offer my perspective on the recent discussions. My apologies 
if I am teaching my grandmother to suck eggs.

At 09:25 AM 26/03/2001 -0500, Berin Loritsch wrote:
>Michael Friedman wrote:
> > With Micah's permission I'm posting this to the list.
> > My concern is that the requirements do not make clear whether the objective
> > is to do a better job of handling forms of the type that are currently done
> > on the web and marginally increase the complexity and power of the forms we
> > can use or if the objective is to let people build powerful and complex
> > forms with tight database integrations like the ones people build with
> > Oracle Developer, PowerBuilder, etc.

To my mind, there is a reason for that.

XForms is designed for defining the UI of three-tier applications, not for 
client/server applications. Trying to shoehorn in client/server support 
would IMHO be a very Bad Thing because client-server and three-tier are 
fundamentally very different things on the client side.

Some might feel that XForms is even more narrowly designed, so that it is 
only intended for browsers connecting to web applications. My hope is that 
people will recognize that there is enough overlap in design that the more 
general solution for three-tier environments can be accommodated.

>It appears to me that XForms is trying to provide a pure XML MVC (Model View
>Controller) pattern.  That means that you have the XForms Model (The model
>portion), XForms DCL and processor (the controller), XForms UI (the view).

I agree with that, but would like to offer a clarification based on my 
understanding.

 From the perspective of the three-tier application, the purpose of XForms 
is to provide the View component. In fact, it promotes very well the 
separation of the View from the Model and Controller of an application on 
the middle tier because it doesn't provide much in the way of tools for 
managing the Model. It would be non-intuitive to deliver much business 
logic to the client using XForms, which is a Good Thing (and the reason I 
don't agree with the quote from Michael Friedman/Micah).

OTOH, the View itself has its own Model and Controller that is UI-based. 
For example, the rule not to enable the "Submit" button until all the 
required fields are filled in, or to provide a component named "Skills" 
that allows for multiple selections. That Model is a different thing than 
the Model of the application, and that is the Model that XForms provides.

Of course, there is also some overlap between the client UI Model and the 
application Model. If a field is restricted to a certain set of values, 
that restriction belongs in both the UI Model and the application Model. 
Putting it in the client minimizes network traffic, and putting it in the 
business logic for the application means that rogue or buggy clients can't 
mess up your Model.

>It is up to you to bind the instance to a real datasource.  That is one of the
>major shortcommings of XForms.  The other is that it assumes that the prefered
>method of dealing with XForms is through a DOM.

How is this a shortcoming? It allows you to provide your application's 
Model to any number of XForm Views. Sounds ideal to me.

I'm not sure I understand your complaint about the DOM, either. Provided 
all the bindings were understood before the instance data was parsed, I 
don't see why there needs to be a DOM. A SAX parser could do the job just 
as well, couldn't it?

>The requirements are still young.  You also have to keep in mind that Database
>integration is only one type of data binding.  What about mapping to EJBs or
>CORBA objects?  There are other standards that deal with that mapping.  I am
>looking at a public domain one that maps XML to a DBMS.
>
>That is also part of the limitation with the XForms Model.  The Model assumes
>nothing other than XML integration.  What is needed is a standard binding 
>language
>that will conform XML to an arbitrary backend--whether it is object based or
>table based.

I understand your points. It is true that this is a limitation. The 
question is, do the benefits outweigh the costs.

Once upon a time, the standard abstract mechanism that all programs could 
rely upon for moving data from place to place was the stream. Unix's 
standard for interprocess communication was the stream. Network 
communication happens with streams. The whole world runs on streams.

In the new world of web services that is dawning, a layer is being added to 
streams. Instead of dealing with streams directly, we will now be dealing 
with trees. XForms provide a tree for a UI model, as well as a tree that 
describes how to bind the model to actual widgets. And they assume one or 
more trees of instance data to bind to. This is why XForms has the 
potential to be the UI of the new world of web services.

Your EJB and CORBA objects can return XML. Or you can go through a web 
service such as a servlet that accesses the EJB and CORBA objects and 
translates their data into XML. Going this route allows better data 
portability and componentization, and it minimizes the interference of 
firewalls. Of course, it also eliminates the whole point of firewalls but 
that is a whole other discussion.

>   I have not looked at XBL (XML Binding Language) yet, but it could
>possibly fill this void.

My reading of it suggests that it is for bindings between DOMs or between a 
CSS and a DOM. I could be wrong.

>If you are talking about rich form controls that you would normally get with
>an application setting, I am not sure how that would be approached.  You would
>almost need a conformance level: embedded devices have to enable the core set
>of UI controls, browser enabled deveices may have to enable a few more, and
>lastly, stand alone applications would have to enable yet another set.

Instead of multiple conformance levels, you can allow each UI to define its 
own bindings from the XForms model to widgets. The XForms UI is only one 
set of widgets that can be used, although it would be nice if it was 
extensive enough to provide for the vast majority of cases while remaining 
slim enough to allow for thin clients. Competing goals, I know. VoiceML, 
WML, Java, Javascript, and so on could all have their own bindings.

It would be nice if there were always a way to provide extensibility, 
though. Say you wanted to add a Hyperbolic Tree Browser to your in-browser 
web application (http://www.inxight.com/). You'd have to provide some way 
of attaching to a Java object within the XForms UI, since it is only 
available in that form right now. It would be nice if that kind of 
functionality could be kept in mind, even if it is outside the scope for 
XForms UI.

Anyway, that's my take. Feel free to shoot holes in my theories.

Received on Monday, 26 March 2001 17:05:06 UTC