Re: Fw: XForms requirements

At 09:25 AM 3/26/2001 -0500, Berin Loritsch wrote:
>Michael Friedman wrote:
> >
> > With Micah's permission I'm posting this to the list.
> >
> > Quick summary:
> >
> > 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.
>
>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).
>
>The separation of the Model and the Controller has alot of overlap, and I am
>not that crazy about that part.  The "richness" of the XForms UI section
>leaves alot of things missing--I think part of the design.  The reason is that
>they are trying to cater to the smallest subset available (wireless devices).

To reach the goals of web users and web service providers of a common approach
to client-service interaction across a spectrum of devices from wireless phones
to 10Mpixels VR displays will require some significant 
compromises.   XFORMs has
many of the elements for these compromises in place.  The missing one is a
"modularization" that will allow clients to work through a minimal 
implementation
or a richer one.  Such a modularization would allow more room for UI 
feature creep
at the high end.

Is there any interest in the XFORMs group in a modularization effort?  I 
know it
is not an easy task, but it would increase adoption rate (by giving an 
incremental
path) as well as addressing the device range problem more directly.

>The Model describes XML schema and dynamic constraints/calculated fields
>for a data instance.  The instance is XML that conforms to the XForms Schema.
>
>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.

I don't understand the first assertion: do you claim that XFORMs should 
bind to a
particular data source?  Perhaps you mean that the lack of XFORMS 
integration tools
for existing data sources is an inconvenience today?


> > My concern is that the need is for the latter, but the requirements cater
> > more to the former.
>
>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 have not looked at XBL (XML Binding Language) yet, but it 
>could
>possibly fill this void.

It isn't practical to build support in to XFORMs for a large range of
backends, but a packaging mechanism for instance data that is likely
to support a large range for backends would be practical.  That is part
of the reason I suggested exploring XMLP integration.  By allowing XMLP
message as instance data, all XMLP services are bound to XFORMs.  The
momentum of XMLP is such that a large number of backends are likely to
support it.


> > I would really appreciate it if some of the people involved in the standard
> > could look at some of the more complex forms in the client/server versions
> > of Oracle Financials, Peoplesoft, or SAP and ask themselves if XForms 
> can be
> > used to duplicate that functionality with a reasonable effort.
>
>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.
>
>I don't know how desirable that is.  Maybe we could take a look at how many
>distinct UI controls there are in use in today's GUIs.  The XForms spec makes
>reference to a few more, but they have not been worked out as of the 
>writing of
>the spec.

As I said above under the name "modularization" I think we need this.

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Monday, 26 March 2001 13:24:09 UTC