Initial reaction to XForms Spec

First I want to say that the spec is a Job well done.  I immediately
wanted to go about creating a method to implement this on the server
side.  Why?  For the same reasons that most web servers are not
serving up XML to users.  XForms provides a good way of mapping
data to the markup sent to the user.

While the XForms Spec states that we can still bind with XHTML, I want
to provide that transformation on the server.  That way I can have the
same XForm serve up HTML with javascript or PDF Forms.  This is all
possible with the use of other specs provided by the W3C (XSLT,
XSL:FO, etc).

However, there are some issues that if they were in the final release
of the XForms spec would make this type of approach difficult or even
impossible in some cases.  I will enumerate them based on the section
numbers in the spec.

7.3.5) Single Select: radio buttons, drop-down menus and list boxes

The markup specified is this:

<exclusiveSelect ref="icecream/flavor">
  <caption>Flavor</caption>
  <item value="a">Vanilla</item>
  <item value="b">Strawberry</item>
  <item value="c">Chocolate</item>
</exclusiveSelect>

Since this markup can represent any of the following: radio, checkbox,
menu, or listbox--there is no direct way to specify that choice.  If I
wanted radio buttons I would have to do something like this:

<exclusiveSelect ref="icecream/flavor" style="list-ui: radio;">
  <caption>Flavor</caption>
  <item value="a">Vanilla</item>
  <item value="b">Strawberry</item>
  <item value="c">Chocolate</item>
</exclusiveSelect>

What happens if the CSS stylesheet is loaded seperately?  On the server
side, I have no way of altering the transformation of the exclusiveSelect
to a radio button group.

I would prefer to see something like the following:

<exclusiveSelect ref="icecream/flavor" type="radio">
  <caption>Flavor</caption>
  <item value="a">Vanilla</item>
  <item value="b">Strawberry</item>
  <item value="c">Chocolate</item>
</exclusiveSelect>

Notice the "type" attribute.  This makes it clear how the exclusiveSelect
element should be rendered, and from a business perspective the type of
list is _very_ important.  I know of people who agonize over those types
of things.  It should have first class status.

I also would like to see a "button" type of exclusiveSelect element.

7.3.6) Multiple Select: Lists

<multipleSelect ref="icecream/flavor">
  <caption>Flavor</caption>
  <item value="a">Vanilla</item>
  <item value="b">Strawberry</item>
  <item value="c">Chocolate</item>
</multipleSelect>

From a designer's standpoint I would like to see this represented as
either "list", "checkbox", or "button".  That way the form can match
a paper form as close as possible, or maintain consistency with an
already developed form for a program.

7.6.3) Grid Layout

There are several GUI libraries that do this arrangement nicely, without
explicit positioning.  Two that come immediately to mind are Java Swing,
and GIMP Tool Kit.  They both have layout managers that take care of the
vertical, horizontal, and grid layouts with minimal work by the user.

Basically it would be translated to XML like this (using your example):

<gridLayout cols="4">
  <textbox ref="dimensions/top">
    <caption>Top</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
  <textbox ref="dimensions/top">
    <caption>Bottom</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
  <textbox ref="dimensions/top">
    <caption>Left</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
  <textbox ref="dimensions/top">
    <caption>Right</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
  <textbox ref="dimensions/top">
    <caption>Center</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
</gridLayout>

Each control ("textbox" and "output") takes up a grid position.  The grid
is filled in the natural language order (For English left-to-right, and for
Arabic languages right-to-left).  When we get to the last column, we
automatically create a new row.

+---+---+---+---+
| T | O | T | O |
+---+---+---+---+
| T | O | T | O |
+---+---+---+---+
| T | O |   |   |
+---+---+---+---+

While this nicely does a hard grids with the fields all automatically
justified sometimes I may want another layout strategy.  The "groupbox"
element works in that context--but the groupbox has a binding context.
The way the afformentioned libraries take care of it is a verticalLayout
and a horizontalLayout.

In XML it would be represented like this:

<verticalLayout>
  <horizontalLayout>
    <textbox ref="dimensions/top">
      <caption>Top</caption>
    </textbox>
    <output ref="dimensions/@unit-of-measure">
    <textbox ref="dimensions/top">
      <caption>Bottom</caption>
    </textbox>
    <output ref="dimensions/@unit-of-measure">
  </horizontalLayout>
  <horizontalLayout>
    <textbox ref="dimensions/top">
      <caption>Left</caption>
    </textbox>
    <output ref="dimensions/@unit-of-measure">
    <textbox ref="dimensions/top">
      <caption>Right</caption>
    </textbox>
    <output ref="dimensions/@unit-of-measure">
  </horizontalLayout>
  <textbox ref="dimensions/top">
    <caption>Center</caption>
  </textbox>
  <output ref="dimensions/@unit-of-measure">
</verticalLayout>

Basically it aligns the elements in its context, but allows for something
like this:

+--------+-------------+
| Text O | Text Output |
+--------+----+--------+
| Text Output | Text O |
+-------------+--------+
|      Text Output     |
+----------------------+

Sometimes this form of layout is more desirable when you are trying to
place a large amount of information in a small space.  Also, you are not
limited to the same number of columns or spacing of columns from row to
row.  This is much better than complex XHTML tables with colspan and
rowspan attributes all over the place.

The important thing to realize about layouts is that they have absolutely
no visible borders or rendered portions.  They are simply placeholders,
and do not have any kind of binding context whatsoever.

This cleanly separates out the form layout from the controls.

It could be contracted into one element called "layout" with a "type"
attribute:

<layout type="grid" cols="2"></layout>

The only problem with that is the "cols" attribute (short for columns)
is only applicable for the "grid" type.  The available types would be
"grid", "horizontal", and "vertical" if we chose the one "layout" element
instead of three different elements.

NOTE:
Since I specified natural language order for the gridLayout element,
we may want to call the "cols" attribute "positions".  The reason
being is that in addition to the left-to-right and right-to-left
ordering, the Chinese language has a vertically oriented language
(top-to-bottom).  The "positions" or "cols" attribute refer to the
cross-sections.  For instance view the following ascii pictures (all
with 3 positions and 5 elements):

European Languages (Left-To-Right Ordering)

+-+-+-+
|1|2|3|
+-+-+-+
|4|5| |
+-+-+-+

Middle East Lanaguages (Right-To-Left Ordering)

+-+-+-+
|3|2|1|
+-+-+-+
| |5|4|
+-+-+-+

Asian (Top-To-Bottom, Right-To-Left? Ordering)

+-+-+
|4|1|
+-+-+
|5|2|
+-+-+
| |3|
+-+-+

Asian (Top-To-Bottom, Left-To-Right? Ordering)

+-+-+
|1|4|
+-+-+
|2|5|
+-+-+
|3| |
+-+-+

Received on Thursday, 22 March 2001 16:25:38 UTC