RE: XForms and separation of UI from data model

Hi Dave,

Great to hear from you!

You suggest that selectBoolean, selectOne, and selectMany be combined into a
single selectFrom form control.

I agree with most of your comments on selectBoolean, so let's leave that for
last.

On selectOne|selectMany -> selectFrom, I didn't notice any distinction
between the "one" and "many" part. This has a profound effect on the
processing model--"many" requires a list-derived Schema datatype or else the
complexType <repeat> processing.

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

I agree that styling is the best way to go. My understanding of selectUI is
that it applies a hint for when no styling information is present.

On to selectBoolean...

> selectBoolean can only be bound to boolean data values

Almost. We allow the author to specify form controls and leave out the
XForms Model (including instance data) for simple cases. In this event,
every datatype would default to xsd:string. With only this information, a
user agent could still make a good determination on how to render a
selectBoolean (vs. selectOne) based on a given presentation (voice, visual,
paper, etc.)

selectBoolean _is_ largely syntactic sugar. It's true that we could do a
better job explaining why we view it as useful.

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

Yes, I agree! The available choices for selectUI should be the same across
the board. I will bring this up before the Group.

>On a separate issue, the description of <range> element leaves it unclear
as to whether you can bind it to integer valued data items.

Hmm, I'll look into this. From a Schema viewpoint, xsd:integer is derived
from xsd:decimal, so it should be allowed. We need to work on cleaning up
the text.

Thanks!

.micah


-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org]
Sent: Friday, September 21, 2001 3:08 AM
To: www-forms@w3.org
Subject: 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 Saturday, 22 September 2001 19:39:34 UTC