RE: XForms and separation of UI from data model

As one of the founding working group members of the XForms
WG, and our W3C staff contact for the first 6 months of the
WG's life, Dave is intimately familiar with the goals and
principles of XForms and he is completely accurate when he
points out that the separation of Model and UI is a key
XForms design goal.  However, his assertion below that
XForms has violated this though disturbing on the surface,
turns out to be mostly due to the fact that Dave has not
been an active participant of the WG for the last 9 months--
during this time,  many of the initial thoughts underlying XForms
have crystalized into a solid working design.

I'll address Dave's concerns below in sequence; Members of
this public list where this discussion has been restarted by
Dave should be aware that the design he proposes below were
debated at length by members of the WG (including Dave) last
year --what you see in the working draft today is a result
of weighing different design choices against one another and
balancing amongst different requirements that XForms needs
to fulfill.  So, although wiping the slate clean and
starting from scratch always makes the "starting from
scratch" look attractive, that is often because all the hard
problems have been swept under the rug --only waiting to
emerge at a later date.

DSR> A stated principle underlying XForms is the separation
DSR>of the user interface from the data model. 

This indeed is a key principle that is being respected --not
violated-- by the August 28 draft.

0) The XForms Model captures the structure and constraints
of the data being populated by the user interaction;

1) The user interaction --designed to be sufficiently
   high-level so we dont end up with another 10 years of
   eye-balls-only WWW interaction--
binds to this model.

DSR> This principle is in my opinion being violated by
DSR> several elements in the XForms user interface as
DSR> described in the working draft dated 28th August 2001: URL: http://www.w3.org/TR/2001/WD-xforms-20010828/slice7.html

As pointed out above,  Dave had raised this discussion within
the Forms WG last October through January, 
and those discussions eventually led to the group's
concensus on how the model and user interface layers
interact.
It is this concensus that you see reflected in the working draft.
 
DSR> The following elements all deal with the selection of
DSR> values: selectBoolean SelectOne selectMany


DSR> The names and definitions of these elements make
DSR> assumptions as to the data model for the associated
DSR> data, for instance, selectBoolean can only be bound to
DSR> boolean data values. 

They do not make "assumptions"--
they ensure that the author creates a user interaction that
is capable of collecting data that matches the underlying
data instance being populated.

DSR> This introduces a degree of
DSR> redundancy into XForms, that could easily be avoided by
DSR> providing a single element that can serve in place of
DSR> all the above elements.

Above, Dave is confusing robust design --where robustness
necessarily needs redundancies at different layers of the
architecture-- with syntactic issue ofs what elements are
called, incorrectly concluding that XForms violates the
separation of model from UI.

The reason we have this level of redundancy
--to summarize the gist of the lengthy debates from a year
ago-- is:

0)  Allowing a single UI control to populate all of the
    available data types in the XForms model
exposes the XHTML author to an unduely high-level of
    authoring errors where these errors manifest themselves
    fairly late --namely at the time the user interacts with
    the WWW application. In  some sense --it creates the bane
    of the HTML WWW.

1) Having a single ui control and relying exclusively on the
   presence of a schema to provide the type constraints is
   not a viable option as we transition to an XForms/XSchema
   powered world.  Notice that XForms 1.0 permits you to
   create simple XForms without a model.

For those on the public list not privy to our original
discussions on this issue-- Dave had long advocated the
XForms WG starting with a clean slate and create our own
simplified version of XSchema; the group abandoned this idea
in favor of re-using W3C technologies.  We further realized
that what the HTML hand-author needed was not a "simple
syntax" for creating a model-- where possible the HTML
hand-author did not want to be bothered with a model at all-- hence
the ability to write simple forms without a model.  Our
design keeps simple things simple and difficult things
possible while not reinventing the wheel in our own
particular shade of pink.

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

I believe that the audit trail of our design discussions on
the group list-- as well as this public explanation serves
to explain and motivate the design --and why the redundancy
is needed and is indeed a good thing.  Classifying this
redundancy as a "violation" is Dave's particular world-view
--and has no place in a formal language specification.  I've
not seen W3C specifications roll out all the design choices
that a WG discusses in the official specification; that
would make W3C specs look even more like a "design by
committee" exercise than they already are.

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

Not only does the above suffer from the "wipe the slate
clean" bug, it violates design requirements motivated by the
need to access the WWW from a variety of devices, and the
realization that users have different needs and abilities
--namely accessibility.

0) It may not always be the right thing to display something
   as a "radio" button --often, the end-user device or UI is
   in a better position to decide how a selection that
   allows mutually exclusive selection should be presented.

1) Notice that what Dave criticizes as "redundancy" is
   actually semantically rich markup 
that enables the client implementing the XForms UI to give
   the user appropriately useful feedback during
   interaction.

2) Even if an XForms model has been defined and present,
that model may live on a server --and what gets shipped to a
 light-weight handheld may be only a user interface.
Leaving all of the semantics at home on the server and
 shipping a graphical button that the user can poke at
 to the handheld client  would seriously damage
 accessibility  of the user interaction to users with
 different needs.

3) Finally, if you bought Dave's grand unification theory of
   UI design exemplified above,
you'd only need one UI control --<input/>
--after all since the model knows the type of the thing
   you're populating it can figure the out the rest.
And of course since we all know to write Javascript, the
   rest is a  SMOP:-)
  
DSR> Comments:
 DSR> - selectUI should be deprecated in favor of a
DSR> corresponding style property

Sadly there is no corresponding style property in CSS.  We
are liaising with the CSS WG on the UI piece of XForms and
do not wish to invent CSS properties inside XForms that are
not present in CSS-- this is commensurate with our overall
goal of re-using W3C technologies, and making sure that the
XForms design does not re-invent or extend the output of
other WGs in xforms specific ways.

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


Notice that the above assertion is the consequence of what
 was swept under the carpet crawling out.
It should also be noted that in some sense the above tangles
 up the model and UI in  bizarre ways --something Dave
 started off by accusing the XForms design of committing.

 DSR> - authors may want to style boolean data items with a
DSR> pulldown or list box etc. and the XForms UI shouldn't
DSR> preclude this - <true> and <false> are syntactic sugar
DSR> for: <choices> <item value="true">...</item> <item
DSR> value="false">...</item> </choices>

The above design of selectBoolean was adopted by the WG
 after  detailed discussions with both  desktop browser
 interests as well as the interests of small devices.
The suggested modification does not appear to add anything
 to  the constraints we balanced in coming up with our
 present design --other than changing syntactic sugar.

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

The "refinement" above is once again re-design happening
 after wiping the slate clean.

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


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

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

Thanks for catching the <range/> issue --I'll fix the error
 for the next working draft.

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)

-- 
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://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

-- 
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://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Saturday, 22 September 2001 22:05:33 UTC