[standards-jig] x:data and XML Forms

Mike Oliver MikeO at theriver.com
Mon Apr 8 16:46:11 UTC 2002


I don't disagree with either Steve or Julian, however, I am not advocating
either x:data or XML Forms. There are two (or more) options (x:data and XML
Forms) because there are reasons someone developed both, why one is favored
by some over the other.  So why choose?

If we have a capability negotiation that can just be a CAPABILITY request
with a response of "CAPABILITIES XDATA XFORMS" OR "CAPABILITIES XFORMS" OR
"CAPABILITIES XDATA" then the two sides can immediately know if the other
side can handle what they want to use.  Then also, later if someone wants to
develop their own or use something else then they can add XPOT OR XPATH to
their capabilities and know that the other side either does or does not know
how to support it.

 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 Stephen Lee
Sent: Monday, April 08, 2002 5:50 AM
To: standards-jig at jabber.org
Subject: RE: [standards-jig] x:data and XML Forms


After re-reading the x:data jep and reading some about Xforms I would
have to say I agree with Julian on this.

Obviously it will make the display of search fields and other data
returned from the server much easier to display in a standard fashion.

Although Jabber uses XML it doesn't support the full features of it
either, it would seem to me that we would want to standardize on
something that is good for jabber.

Having jabber support excessive amounts of 'extra' baggage does not seem
to me to be a wise move.

Steve

-----Original Message-----
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org] On Behalf Of Julian Missig
Sent: April 5, 2002 3:45 PM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] x:data and XML Forms


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



_______________________________________________
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mike Oliver.vcf
Type: text/x-vcard
Size: 139 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020408/74ffdce7/attachment.vcf>


More information about the Standards mailing list