W3C home > Mailing lists > Public > www-forms@w3.org > January 2001

RE: Review of XForms working draft

From: Welsh, Linda B <linda@intel.com>
Date: Thu, 4 Jan 2001 11:39:35 -0800
Message-ID: <9678C2B4D848D41187450090276D1FAE03E0768A@FMSMSX32>
To: "'Michael Earls'" <michael@cerkit.com>, www-forms@w3.org
That was really nice of you to say....Thank you Michael!

----------------------------------------------------------------------
Linda Bucsay Welsh <mailto:linda@intel.com>
Web Standards & Architecture Team (WSAT)
Intel Architecture Labs
503.264.4987 - Desk
503.799.7091 - Cell
503.264.3375 - Fax 
----------------------------------------------------------------------



>-----Original Message-----
>From: Michael Earls [mailto:michael@cerkit.com]
>Sent: Tuesday, January 02, 2001 8:22 PM
>To: www-forms@w3.org
>Subject: RE: Review of XForms working draft
>
>
>> We might well feel that max-inclusive etc are "too cmplex"
>> according to some as yet undefined complexity measure;
>> however we are not making things simpler by adding quirks of
>> our own that appear "simpler" to us --the rest of the world
>>  will just remain confused.
>>
>We mere mortal business implementors do understand the notion 
>of defaults
>and we love shortcuts.  We aren't entirely retarded.  We're 
>doing pretty
>well adjusting to that complicated wrench that Microsoft threw 
>at us when
>they added the "style" attribute beside the already complicated "class"
>attribute. Most of my developers have recovered but I still 
>have a few who
>get mixed up and avoid CSS altogether.  (I _am_ joking)
>
>On a more serious note...
>
>I want to take this chance to thank each of you for working so 
>dilligiently
>to define what I consider one of the most effective 
>time-savers a business
>web application developer will ever implement.  XForms are 
>what I wish I had
>had five years ago.
>
>It will allow us to finally make a generic UI engine and focus 
>on what we
>are really here to do... our respective business domain 
>programming.  I'm
>getting tired of having to re-invent the UI for every new project.
>Schema-based programming combined with XForms will certainly 
>provide a rich
>framework for our future development efforts.
>
>Thanks again and keep up the good work!
>
>Michael Earls
>
>----- Original Message -----
>From: "T. V. Raman" <tvraman@almaden.ibm.com>
>To: "Micah Dubinko" <MDubinko@cardiff.com>
>Cc: <gilescope@yahoo.co.uk>; <www-forms@w3.org>
>Sent: Tuesday, January 02, 2001 11:37 AM
>Subject: RE: Review of XForms working draft
>
>
>> On 1: I would strongly advocate against our continuing to
>> cook up our abbreviated versions of max-inclusive and
>> friends.
>> I believed this at the FTF --the review comments only
>> strengthen this belief.
>>
>> We might well feel that max-inclusive etc are "too cmplex"
>> according to some as yet undefined complexity measure;
>> however we are not making things simpler by adding quirks of
>> our own that appear "simpler" to us --the rest of the world
>>  will just remain confused.
>>
>>
>> >>>>> "Micah" == Micah Dubinko <MDubinko@cardiff.com> writes:
>>
>>     Micah> Giles, Thanks for your time and feedback.
>>
>>     Micah> on 1) - I believe you are correct. Is this
>>     Micah> confusing enough that we should consider just
>>     Micah> leaving the inclusive/exclusive versions and skip
>>     Micah> the abbreviated one alltogether?
>>
>>     Micah> on 2) - I like this idea. We will consider
>>     Micah> something along these lines for our ongoing
>>     Micah> research with the XForms Processing Model.
>>
>>     Micah> Thanks!
>>
>>     Micah> Micah Dubinko Co-editor, W3C XForms Working Group
>>
>>     Micah> -----Original Message----- From: Giles Cope
>>     Micah> [mailto:gec@hyperoffice.com] Sent: Tuesday,
>>     Micah> January 02, 2001 4:37 AM To: www-forms@w3.org
>>     Micah> Subject: Review of XForms working draft
>>
>>
>>     Micah> 1. 'max' for Number should be short for
>>     Micah> maxInclusive not maxExclusive (and 'min'
>>     Micah> respectivly).
>>
>>     Micah> 2. In 9.4: We do need a syntax to work on
>>     Micah> multiple models but,
>>
>>     Micah> <xfm:textbox
>>     Micah> ref="instance::b/orderForm/shipTo/firstName">
>>
>>     Micah>    but we loose the idea of the current context
>>     Micah> using this syntax, and have to specify everything
>>     Micah> from the root.
>>
>>     Micah>    We need something like:
>>
>>     Micah> <xfm:textbox
>>     Micah> ref="instance::b./shipTo/firstName">
>>
>>     Micah>    but obviously with better syntax. Maybe we
>>     Micah> could select the current context in the binding
>>     Micah> element:
>>
>>     Micah> <xfm:bind> <xfm:select="orderForm/shipTo/">
>>     Micah> <xfm:bind id="myfirstname" ref="firstName""/>
>>     Micah> <xfm:bind id="myaddresszip" ref="address/zip"/>
>>     Micah> </xfm:select> </xfm:bind>
>>
>>     Micah> my two cents, gilescope@yahoo.co.uk
>>     Micah> ----------------------------------------------------------
>>     Micah> "My sole reply," said he, "to that demand Is
>>     Micah> action; when a fit request is made Silence and
>>     Micah> deeds should follow out of hand."  -- Virgil
>>     Micah> [Canto XXIV, 76]
>>
>> --
>> Best Regards,
>> --raman
>> ------------------------------------------------------------
>>
>> IBM Research: Human Language Technologies
>> Phone:        1 (408) 927 2608
>> Fax:        1 (408) 927 3012
>> Email:        tvraman@us.ibm.com
>> WWW:      http://www.cs.cornell.edu/home/raman
>> PGP:          http://cs.cornell.edu/home/raman/raman.asc
>> Snail:        IBM Almaden Research Center,
>>               650 Harry Road
>>               San Jose 95120
>
>
>
Received on Thursday, 4 January 2001 14:39:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT