[standards-jig] x:data and XML Forms

Julian Missig julian at jabber.org
Fri Apr 5 20:44:36 UTC 2002


I don't think we should bother with any of that if we use x:data. x:data 
is *not* very complicated. It's pretty simple for what it does, and I 
see no reason why a client cannot support all of it. It's XForms that is 
incredibly complicated, but the levels of support for that are defined 
by the W3C, and Basic is far too complicated still. I say we do x:data 
and have clients support either all or none of it.

Julian

Mike Oliver wrote:

>The problem with 'Levels' is that Clients must implement all of the features
>of a 'Level' and that is what I think we want to avoid.  I think a
>negotiation between parties on a capability by capability basis is much more
>flexible and serves every possible need, including x-capabilities individual
>pairs of Clients can support without anybody else on the planet knowing
>about what that x-capability does.  If you want to package some capabilities
>together you can do that too.  An example is how POP3 and IMAP4 publish
>capabilities and negotiate the provisions on a session/client by
>session/client basis.
>
> God Bless America!
>Michael Oliver
>Chief Technology Officer
>Morningstar Systems Inc.
>7391 S. Bullrider Ave.
>Tucson, AZ 85747
>520.574.1150 Voice
>520.447.2736 eFax
>520.891.1213 Mobile
>"Learn as though you would never be able to master it;
>hold it as though you would be in fear of losing it."
>Confucious (551-479 BC); Chinese philosopher.
>
>
>Click here
>to chat.	 hotComm Link <http://ollie.im-live.com/im-live/>
>
>If I'm not immediately available, please try later
>or check my ezPeer home page at
>www.ollie.ezpeer.net <http://www.ollie.ezpeer.net>
>
>
>Click to subscribe to KMPro <http://groups.yahoo.com/group/KMPro/join>
><http://www.qksrv.net/click-1031152-5675190>
>
>
>-----Original Message-----
>From: standards-jig-admin at jabber.org
>[mailto:standards-jig-admin at jabber.org]On Behalf Of Justin Kirby
>Sent: Friday, April 05, 2002 9:40 AM
>To: standards-jig at jabber.org
>Subject: RE: [standards-jig] x:data and XML Forms
>
>
>What about support levels?
>
>Instead of going all or none, define levels of x:data support... e.g.
>level 0 is current, level 1 is partial XForms... etc...
>
>I know ODBC does this for driver compliance, and you can query the
>driver for the levels it supports.  This seems more reasonable and
>allows for ppl to implement features they think are worth the effort and
>also allows ppl to follow KISS...
>
>On Tue, 2002-04-02 at 22:09, Thomas Muldowney wrote:
>
>>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
>>>>>>






More information about the Standards mailing list