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

Thanks

Julian

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
http://mailman.jabber.org/listinfo/standards-jig



More information about the Standards mailing list