W3C home > Mailing lists > Public > www-forms@w3.org > March 2001

Re: Fw: XForms requirements

From: Berin Loritsch <bloritsch@apache.org>
Date: Mon, 26 Mar 2001 13:39:29 -0500
Message-ID: <3ABF8CE1.A2F71759@apache.org>
To: "John J. Barton" <John_Barton@hpl.hp.com>, XForms Mailing List <www-forms@w3.org>
"John J. Barton" wrote:
> 
> 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:
> > >
> >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?

I think that the XForms model should either specify a method of binding to
a real datasource, or reference another spec that is designed to provide
that service.  The reality of enterprise application development is that
XML is not the storage medium, but the transport medium.  Smaller companies
that do not have the XML mapping objects already developed would want to
look into a standard methodology of binding to a real datasource.  Let's
face the facts: databases can be quicker, more stable, and scalable than
filesystems.  Especially when we are talking about dynamically creating,
modifying, and destroying data.

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

OK.  Not everyone has a messaging service as part of their solution.  I am
creating a product that fills the binding of the instance data directly to
an arbitrary datasource.

I am using the XForms spec to create a Model, a custom Processor for the
form, and transform the UI to the client's native format.  I want to
leverage an established binding language to create the direct to archive
storage and retrieval mechanisms.  If one is not available, then I will
create one.
Received on Monday, 26 March 2001 13:42:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT