W3C home > Mailing lists > Public > public-forms@w3.org > February 2008

Re: Decision Point on XForms 1.2

From: T.V Raman <raman@google.com>
Date: Tue, 19 Feb 2008 16:32:28 -0800
Message-ID: <18363.29980.294012.741027@retriever.corp.google.com>
To: wiecha@us.ibm.com
Cc: boyerj@ca.ibm.com, public-forms@w3.org, public-forms-request@w3.org

1+ on this. This will also move things a lot faster than the W3C process.

Charles F Wiecha writes:
 > With regrets (both for having to agree, and for missing next week): +1
 > As we discussed at the F2F, a good way to proceed on these would be to do
 > implementations (code, not spec) in open source and then capture the
 > results in small "consumable" module documents...Charlie
 > Charles Wiecha
 > Manager, Multichannel Web Interaction
 > IBM T.J. Watson Research Center
 > P.O. Box 704
 > Yorktown Heights, N.Y.  10598
 > Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
 > wiecha@us.ibm.com
 >   From:       John Boyer <boyerj@ca.ibm.com>                                                                                        
 >   To:         Forms WG (new) <public-forms@w3.org>                                                                                  
 >   Date:       02/14/08 03:01 PM                                                                                                     
 >   Subject:    Decision Point on XForms 1.2                                                                                          
 > Further to our telecon discussion about how to decide what's in or out of
 > XForms 1.2, there is a decision to be made here.
 > Right now, I think XForms 1.2 is too big compared to what was really
 > mandated by our charter.  This is one reason I put all remaining "possible
 > 1.2 or high 2.0 features" into 2.0.  But it doesn't seem like that goes far
 > enough.  I have a proposal below to cut scope for 1.2, but first let's
 > review what's currently listed.
 > The features currently listed for 1.2 in the wiki
 > 1) ease-of-authoring patterns that are consistent with the expectations set
 > forth in our charter.  As a side note, we have *lots* of other ease of
 > authoring ideas, some are listed in 2.0 (like) AVTs and some have crept up
 > into 1.2 (like the repeat pattern).   But none of these go into the bucket
 > we are calling "ease of authoring" patterns because this bucket is targeted
 > at the "transitional" XForms on-ramp concept in our charter for 1.2.  We
 > need a better name than the one we have, but I think it will be used to
 > describe the overall release if the proposal below is acceptable.
 > 2) User interface patterns.  A number of these seek to to capture what
 > people are doing with sets of our form controls that interact together
 > toward a common purpose. But some (like the wizard pattern), I think we do
 > not know well enough to codify something useful, and it will take too long
 > for 1.2 to figure it out.
 > 3) Composition patterns.  This has exciting stuff like nested models and
 > external models.  It also has stuff which could be looked at as being other
 > than composition, like the function definitions.
 > 4) Modularization. This work seems inevitable in order to do the
 > "simplification"/"transitional"/"on-ramp" work.
 > PROPOSAL: I propose that we drop the 'patterns' theme for XForms 1.2 and
 > instead focus on the core charter mandate.  I don't have a great name for
 > it yet, and I could use some help in this area.  But it's something more
 > like "XForms 1.2: Streamlined for Web Application Authors" .
 > Details::
 > i) I don't think we need three subthemes.
 > ii) I think everything in our current "ease-of-authoring" bucket fits into
 > this new theme.
 > iii) I think we have to do the switch/using construct because it is a bug
 > fix to the language, and we still need to do some of those.  But the other
 > "UI patterns" should be pushed off to 2.0 or later.
 > iv) I think that the "custom XPath functions" fits this theme, in part
 > because the XPath function implementations could be provided by Javascript.
 > But otherwise, the composition patterns really need to be deferred to 2.0
 > (as much as it pains me to say that).
 > v) We really need to modularize what we have so that it can be made
 > incrementally available to authors.  It fits the theme perfectly and will
 > streamline our ability to add more to XForms in the future.
 > Please consider this carefully and provide your feedback as soon as
 > possible, esp. those who sent regrets for next week's call.  We need your
 > feedback this week if at all possible.
 > Thanks,
 > John M. Boyer, Ph.D.
 > Senior Technical Staff Member
 > Lotus Forms Architect and Researcher
 > Chair, W3C Forms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail: boyerj@ca.ibm.com
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 > Blog RSS feed:
 > http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw

Best Regards,

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Wednesday, 20 February 2008 00:34:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:56 UTC