Re: A forms-lite straw man

Hi Matthew,

I'm pretty sure I didn't say or even imply that we were interested in 
discarding the label element.

My prior post was not meant to be complete, spec-ready text but rather a 
single, isolated example.

If you have a label with a for attribute, whether or not it contains the 
control that it is "for", clearly that should be used as the implied value 
of the xforms:label, but if you don't have the label, then the content of 
name would be used.

XForms is accessibility-friendly so each control *must* have a label, 
which means that when one isn't provided by the HTML markup, we would 
still have to define something as the label in order to map into the 
XForms conceptual model.  Technically, we could just map empty string, but 
the content of the name attribute is better than nothing.

The overall point, though, is that we should be able to make a reasonably 
complete and flexible mapping from HTML into XForms land to minimize 
required document changes needed to access new features.  If the following 
appears:

  <label for="f1">Given name</label>
  <input id="f1" name="given" type="text"/><br />

Then, we would define the processing for that to be "equivalent to" what 
we have already specified for:

<xf:model>
  <xf:instance xmlns="">
      <data>
         <given></given>
      </data>
  </xf:instance>
</xf:model>

<xf:input ref="given">
   <xf:label>Given name</xf:label>
</xf:input>

The above would make it easier for authors to write the smaller documents 
and to port existing documents to XForms, and the clearly defined mapping 
would make it easier to create conversion tools that would allow the less 
sophisticated author to write what he knows, then convert to an explicit, 
and come to understand the new syntax, which he could then extend via 
advanced features of XForms that are more difficult express as attributes 
of the UI controls.

The bottom line is that people talk about separation of data and 
presentation, but less sophisticated users need a little help getting that 
separation to occur, and we have an opportunity to not only to help them 
do that but also to define new style HTML in a way that allows that 
separation to exist conceptually even when it isn't expressed in the 
document serialization.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Matthew Raymond <mattraymond@earthlink.net> 
Sent by: public-appformats-request@w3.org
09/05/2006 06:22 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
public-appformats@w3.org
Subject
Re: A forms-lite straw man







John Boyer wrote:
> 
> Hi Dave,
> 
> This is a good start.
> 
> I was also thinking that inputs should allow optional use of 'name'
> attribute instead of ref *and* label. This would allow implicit creation
> of a 'flat' data structure.

   There's no point of deliberately discarding the <label> element in
(X)HTML. If there's no <label> for the element, then you could use the
|name| attribute as an unofficial label for general processing, but it
shouldn't replace <label> in the sense that it's used in HTML right now.

   Also, <label> inside <input> should be avoided. Web authors may see
that <input> has a close tag and assume that the contents are actually
the control value, similar to <textarea>, so having the <label> inside
is counterintuitive.

> Then, I was thinking that an input could also use a value attribute
> (content string, not XPath) to indicate initial value of the named node
> in the implicit flat data model.
> 
> The point is that this:
> 
> <input name="Name" value="John"/>
> 
> would do the same thing as an XForm today would do with
> 
> <xf:model>
>    <xf:instance xmlns="">
>        <data>
>          <Name>John</Name>
>       </data>
>    </xf:instance>
> </xf:model>
> 
> <xf:input ref="Name">
>    <xf:label>Name</xf:label>
> </xf:input>

   +1, although I'd like to state again that we still need HTML <label>
elements for fallback.

| <form [...]>
|   <label>Enter your name:
|     <input name="Name" value="John"/>
|   </label>
| </form>

   Hmm. Now that I think of it, UI labels are not the same as labels for
individuals units in a data model.

   I strongly advocate keeping form for backwards compatibility. It can
be safely ignored when its XForms equivalent is present.