ACTION-1773 - Bruchez to write use cases for non-repeat separate label binding

All,

The crux of the issue at hand is that current XForms markup such as:

<input>
  <label>Name</label>
  <hint>Please enter your name</hint>
</input

provides limited flexibility for styling with CSS.

The markup above is quite abstract, which is good in several ways.

For example, visually, when used with HTML, the markup above is typically
represented as label text somewhere near an input box. The hint is
represented inline, as a popup, possibly as background text in the empty
field. This flexibility is commendable.

Implementations often translate such markup into something else into the
HTML DOM. For example, our implementation allows for something loosely like:

<span class="xforms-input" id="foo">
  <label ref="foo-input">Name</label>
  <input id="foo-input"/>
  <span class="xforms-hint">Please enter your name</span>
</span>

I don't know much about what other implementations do, but I notice that
XSLTForms produces also a series of <span> elements, and obviously the
<label> and <input> elements.

With such concrete markup, CSS can be used to organize how label, input box
and hint are organized, using "display:", "float:", etc. CSS properties. But
there are limits, for example, you cannot specifically dispatch the various
elements to different table <td>s or <div>s. For that, you would have to use
an XSLT, client-side DOM or similar transformation.

So as a concrete example, in our little Expresso Order demo [1], we want to
accurately specify on each row the layout within a table [2]. For example:

    <tr>
        ...
        <td><xf:input id="quantity-input" class="quantity-input"
ref="quantity"/></td>
        <td><xf:alert for="quantity-input"/></td>
    </tr>

Here the form author uses the `for` attribute for labels and alerts to have
precise control over where these parts of the XForms control actually get
positioned.

Note that there is a repeat, but that's different from the "table header"
scenario considered during last call: here the `for` doesn't cross repeat
iteration boundaries.

So that's for one specific use case, which illustrates the general category
of use cases where precise positioning of e.g. a label within other markup
elements is needed.

One big benefit of the `for` approach is that it is familiar to HTML
authors.

-Erik

[1] http://www.orbeon.com/beta/xforms-espresso/
[2] http://goo.gl/VlsOG