XForms and separation of UI from data model

A stated principle underlying XForms is the separation of the user
interface from the data model. This principle is in my opinion being
violated by several elements in the XForms user interface as
described in the working draft dated 28th August 2001:

 URL: http://www.w3.org/TR/2001/WD-xforms-20010828/slice7.html

The following elements all deal with the selection of values:

  selectBoolean
  SelectOne
  selectMany

The names and definitions of these elements make assumptions as to
the data model for the associated data, for instance, selectBoolean
can only be bound to boolean data values. This introduces a degree
of redundancy into XForms, that could easily be avoided by providing
a single element that can serve in place of all the above elements.

The XForms specification should either make a clear case for why
this redundancy (and violation of separation of presentation from
data model) is justified, or it should drop the elements in favor
on a solution that conforms to the XForm design principles.

Here is a possible solution:

  <selectFrom
    (single node binding attributes)
    (common attributes)
    selectUI = ("radioGroup" | "checkboxGroup" |
                "pulldown" | "listbox" | "comboGroup")
  >
    <!-- unordered: (caption, help?, hint?, alert?,
                   action?, choices?, true?, false?) -->
  </selectFrom>

Comments:

 - selectUI should be deprecated in favor of a corresponding
   style property

 - it should be possible to condition style rules on the
   data types as expressed in the referenced XForms data model
   (e.g. use checkboxes for all boolean values and radio groups
    for all single select enumerations)

 - authors may want to style boolean data items with a pulldown
   or list box etc. and the XForms UI shouldn't preclude this

 - <true> and <false> are syntactic sugar for:

    <choices>
      <item value="true">...</item>
      <item value="false">...</item>
    </choices>

   A refinement might be to allow <true> and <false> as
   alternatives to <item> within the <choice> element
   rather than as alternative to <choice>, e.g.

    <choices>
      <true>...</true>
      <false>...</false>
    </choices>

 - it might be worth adding "checkbox" to selectUI for use
   with boolean values, but perhaps "checkboxGroup" is ok

On a separate issue, the description of <range> element leaves it
unclear as to whether you can bind it to integer valued data items.
The text says "only datatypes that form a continuous range",
however, integers define a sequence of discrete values. I would
suggest the text mentions integer values along with decimal values.

Regards,

-- Dave Raggett <dsr@w3.org> or <dave.raggett@openwave.com>
W3C Visiting Fellow, see http://www.w3.org/People/Raggett 
tel/fax: +44 122 578 3011 (or 2521) +44 771 213 7629 (mobile)

Received on Friday, 21 September 2001 06:07:44 UTC