Re: Fw: XForms requirements

there are of course multiple ways to slice this problem.
Because we have separated the data model from the user
interface in XForms and define a standardized binding
mechanism for binding UI to the data model,
you can implement your application by using all three pieces
of XForms --namely, data model, binding, and UI--
--alternatively you can use the XForms framework and build
upon the components that suit your needs.
For instance, you might use the data model layer as is to
obtain automatic back-end validation using standard XML
tools,
--and bind a UI authored however you like to this data model
using the XForms binding mechanism.

What you'd gain:

a) All the benefits of your UI widgetry and  --perhaps UIs
authors in SVG for example--

B) Still retain a rich data model that allows other UIs to
bind to it --this is a crucial advantage.

Without the separation outlined here, in today's world, all
too often 
applications get authored purely based on UI constraints
e.g.:
"I have a high-quality display --and I'm going to author a
very rich visual UI"--
later the app-designer discovers that his app is now
inrrevocably tangled up in the UI --and if he needs 
to bind another UI to the same app, he will basically end up
rewriting his app for that other UI.

If XForms are designed right  the only rewriting you would
potentially do is to rewrite the UI layer.

>>>>> "John" == John J Barton <John_Barton@hpl.hp.com> writes:

    John> 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).

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

    John> Is there any interest in the XFORMs group in a
    John> modularization effort?  I know it is not an easy
    John> task, but it would increase adoption rate (by
    John> giving an incremental path) as well as addressing
    John> 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.

    John> I don't understand the first assertion: do you
    John> claim that XFORMs should bind to a particular data
    John> source?  Perhaps you mean that the lack of XFORMS
    John> integration tools for existing data sources is an
    John> 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.

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

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

    John> ______________________________________________________
    John> John J. Barton email: John_Barton@hpl.hp.com
    John> http://www.hpl.hp.com/personal/John_Barton/index.htm
    John> MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road
    John> phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX:
    John> (650)-857-5100^^ݳLEj!{jrڞr薈"zw4vnV_۽a&j)ڙnoܢe[m0rzYyۿjs?mrzYyۿjjfJv0	fiקEj!	zAڮRjrhy

Received on Monday, 26 March 2001 19:27:09 UTC