Re: XForms: Question about tax form example

Erik Bruchez wrote:
> Aaron Reed wrote:
> 
>> We created this particular XForm to give an example of what a user's 
>> experience is with XForms.  It is not, however, a good example of 
>> proper XForms authoring (as noted in the Disclaimer toward the top of 
>> the form source).  Due to a variety of limitations that currently 
>> exists in our XForms implementation, we could not achieve the 
>> table-type of layout that we desired in any other way.  When our next 
>> preview release comes out and we can achieve the desired layout in the 
>> 'proper' way, we'll update these samples and include new samples.
> 
> 
> Thanks for the explanation.
> 
>> As far as bugs, there is nothing that says that a label MUST be 
>> contained in a form control, though that is often the case and is 
>> pretty much what it was designed for.  So the fact that a label will 
>> render outside of a form control is not a bug.
> 
> 
> The spec says (8.3.3):
> 
> "This required element labels the containing form control with a 
> descriptive label."
> 
> That is also how the xforms:label element is used in the XForms spec 
> examples. See section 2.1 for example:
> 
> "Form controls always have labels directly associated with them as child 
> elements—this is a key feature designed to enhance accessibility."
> 
> See also section 8.1, "8.1 The XForms Form Controls Module". The label 
> element is part of the minimal content model for most of the elements 
> there. Section 9.1, "9.1 The XForms Group Module", shows that you can 
> have one optinal label within xforms:group elements.
> 
> Based on this, the xforms:label element:
> 
> 1. Has a containing form control
> 2. Is required exactly once within most form controls
> 3. Is sometimes optional (but with one occurrence at most), for example
>    within xforms:group
> 
> So I stand by my initial claim that this is a bug, and that you cannot 
> use xforms:label the way the Tax form example does. I would definitely 
> appreciate a convincing argument (i.e. reference to the spec and/or 
> errata) saying otherwise.
> 
> -Erik

Hi Erik,

I agree with 2 and 3.  1 should be 'may have a containing form control'. 
   In none of the quotes you provided (nor anywhere in the spec) is 
label restricted to only being a child of certain form controls. The 
fact that formsPlayer, X-Smiles, and Novell's XForms processors all 
render labels outside of controls without error leads me to believe that 
we are behaving correctly.  We are compatible with other implementations 
who have a similar interpretation of the spec.  If the WG wanted labels 
only contained in form controls, then they could have enforced this in 
the XForms schema or turned the label into an attribute on a form 
control, but they didn't.  Because it isn't restricted by the spec, then 
we should allow the form author maximum flexibility while maintaining 
compatibility with other implementations.  We can't always predict how a 
form author may chose to use a control to meet their needs.

More on this topic is addressed by this thread in the W3C's mailing list 
archive: http://lists.w3.org/Archives/Public/www-forms/2005Mar/0066.html

Thanks for your comments,
--Aaron