[standards-jig] x:data and XML Forms

Thomas Muldowney temas at box5.net
Wed Apr 3 03:09:47 UTC 2002


I'm not advocating either method, I'm merely trying to get a decent
amount of discussion before we fully reverse direction on something
that's already before the council.

--temas


On Tue, 2002-04-02 at 14:12, Max Metral wrote:
> And so you're recommending building something entirely different in the
> meantime?  How is that better than implementing something "inspired by"
> their standard?
> 
> -----Original Message-----
> From: Thomas Muldowney [mailto:temas at box5.net]
> Sent: Tuesday, April 02, 2002 2:57 PM
> To: standards-jig at jabber.org
> Subject: RE: [standards-jig] x:data and XML Forms
> 
> 
> I have a few problems.  First, I'm not a big fan of only partially
> implementing a standard.  This creates situations like Netscape and IE
> for HTML.  The standard is a standard as a whole, not in pieces.  If it
> marks portions as optional, fine don't implement those, but if it's not
> optional, you need to support it.  Which ties into my other main
> concern, if we look at the XForms spec as posted in the last call
> working draft I'm not seeing it flag bindings and multiple forms in a
> document as optional.  This means we probably need to understand XPath
> more complete in clients as well as the server.  It also adds a lot more
> namespace usage, which we're still struggling to figure out how to
> tackle.   
> 
> While this may be useful in the future (read: once it's an official
> standard), I think we need to be realistic about what we can go forward
> with in the now.
> 
> Food for thought
> 
> --temas
> 
> 
> On Sat, 2002-03-30 at 23:06, Max Metral wrote:
> > 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
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig





More information about the Standards mailing list