[standards-jig] x:data and XML Forms

Max Metral Max.Metral at peoplepcHQ.com
Sun Mar 31 05:06:36 UTC 2002

I don't claim to be knowledgeable on this particular subject, but just a
suggestion (i.e. discard at will).  If there are PARTS of XForms you need,
even if they don't meet a "basic" package standard, it would seem BETTER to
use our own definition of a subset XForms rather than inventing a new
thing...  That way we at least have a SHOT that XForms tools and software
can work with it, and people can implement the "basic" version at their
whim, rather than being in a totally different ballpark.

-----Original Message-----
From: Julian Missig [mailto:julian at jabber.org]
Sent: Saturday, March 30, 2002 9:55 PM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] x:data and XML Forms

Ok, cool. After reading more of XForms and hearing this I'm satisfied.

Even though XForms claims to try to work with all the GUI situations we
want to be working with, it quickly became apparent that you have to
implement a *lot* even to comply with XForms Basic (all the XPath stuff
and events, etc)... most of which it seems we don't want right now.



On Sat, 2002-03-30 at 21:29, Ryan Eatmon wrote:
> We looked into XForms, and a few other XML based GUI things, before 
> coming up with x:data.  The problem is that we needed something that is 
> data gathering only and not a GUI definition.  Remember that this 
> solution needs to work across all clients, no matter the interface they 
> use.  So XForms is overkill.  And trying to scope the Data Gathering to 
> a subset of XForms is not practical either.  It's like trying to say 
> that we need a screw driver, and giving people a swiss army knife.  You 
> just begging to abuse the purpose behind this idea.
> Here's my own personal two cents.  There are two ways to approach a JEP 
> and adding new things into Jabber.  You can scope out a specific problem 
> and target a solution that solves what you want.  Or you can propse a 
> general idea and spend a long, long time trying to come up with a 
> solution that fits every conceivable future use.
> We chose to tackle the idea of gathering data and not defining the 
> actual GUI form, hence the change of name from x:form to x:data.  When 
> you start opening the can of worms of GUI definition you quickly have a 
> slew of issues and ideas that everyone and their dog wants to solve. 
>  And so you need a solution like XForms.  If somone else want to tackle 
> the GUI definition and make it work for all Client types, then feel 
> free.  All I wanted was a better way of gathering data, and I feel that 
> x:data gives us just that.
> Our thought was that it would be possible to use XForms to define how 
> the form looks, while x:data defines how the asker wants the data to look.
> Julian Missig wrote:
> >On Sat, 2002-03-30 at 15:20, Julian Missig wrote:
> >
> >>Is anyone here at all familiar with w3c's XML Forms? I haven't looked
> >>into them at all, but I was curious as to how they compare with what
> >>we're trying to do with x:data: http://www.jabber.org/jeps/jep-0004.html
> >>
> >>It would be interesting to see if we should bother with x:data or try to
> >>use XML Forms.
> >>
> >
> >Anyway, after a cursory overview it looks to me like XForms is doing
> >what we're trying to do with x:data, although naturally it includes a
> >lot more complicated features. I think it definitely merits some
> >investigation before we all decide x:data is ok...
> >
> >Julian
> >

Standards-JIG mailing list
Standards-JIG at jabber.org

More information about the Standards mailing list