W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: A forms-lite straw man

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 6 Sep 2006 09:57:22 -0700
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-appformats@w3.org, www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFF8CE26C5.D5767CAF-ON882571E1.005B6A5D-882571E1.005D2F42@ca.ibm.com>
Hi Lachlan, 

I think my reply did answer your question.

As my prior email indicated, I was referring to the idea that a future 
version of XForms (say 1.2 for the sake of argument) could be modified so 
that an XForms processor which reads

<input name="Age" type="integer" />

could behave in the same manner as if it had received the more verbose 
syntax under an earlier processor.  So it would create the same internal 
data structures as it does today via the longer syntax.

I didn't describe a specific implementation strategy.  In fact, I'm not 
sure I would as that isn't the goal of the spec.

As for having no effect on existing HTML 4 forms, I would say that the 
above approach is completely orthogonal to that concern.  We have 
separately proposed other ideas to solve that problem. 

So, let's say you receive some text/html, and you read the very first tag 
of it and find that 

1) the html tag is in the XHTML namespace, and it has a version attribute 
of version="1.2"

2) the html tag is in any other namespace, and it has a version attribute 
of version="5"

If these conditions are met, then you just received content that is 
new-style HTML new goodies are at your disposal. If HTML 5, run converter 
to get XHTML 1.2, at which point the complaint against using the XForms 
conceptual model runs out of steam.

If neither of the above conditions are met, then you have HTML 4, so run 
only your old code (ignore tags corresponding to the new features). 

It should be clear from this that you don't break the old forms.  It 
should also be clear that the issue of old forms is therefore orthogonal 
to the first issue described in this mail involving the interpretation of 
additional attributes on elements like the xforms 'input'.  The additional 
attributes are being discussed to help ease the authoring burden of 
migrating up to new-style HTML, so that there is less work to do to get 
the new features.

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

Lachlan Hunt <lachlan.hunt@lachy.id.au> 
Sent by: www-forms-request@w3.org
09/05/2006 08:23 PM

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

John Boyer wrote:
> For easier reading to others, here is a repeat of what Lachlan asked:
>> Having said that, though, I may be interested in merging the two in a 
>> way that doesn't involve retrofitting the syntax of one into the other. 

>>  I'm *still* waiting for John Boyer to explain his intriguing binding 
>> idea that he briefly mentioned earlier, which seemed to do just that.

Actually, the question I was referring to [1] was this:

| Are you suggesting that the XForms content could be bound to
| the input element in XBL sense (i.e. using shadow content trees,
| etc.) or that the input element in the DOM gets replaced with
| the equivalent XForms content?  If it's something completely
| different, please explain.

> It just seems to me to be easy to say something like:
> <input name="Age" type="integer" ... />
> is a shorthand for an implied xforms model in which the following 
> <xf:model>
>     <xf:instance xmlns="">
>       <data>
>          ...
>          <Age>40</Age>
>          ...
>       </data>
>    </xf:instance>
>    <xf:bind nodeset="Age" type="xsd:integer"/>
> </xf:model>
> <xf:input ref="Age">
>    <xf:label>Age</xf:label>
> </xf:input>

I still can't can't quite grasp the concept of how this would work, how 
it would be implemented by UAs and what effect that would have upon 
existing HTML 4 forms?  I'm sure you're aware that altering the 
functionality of existing HTML 4 forms needs to be done in a way that 
will not break any existing sites, so I really have no clue how that 
would work.

Given that XForms submits in XML format and HTML 4 forms traditionally 
use URL encoding (i.e. name=value&name2=value2...), would this binding 
only occur when the author includes something that explicitly requests 
this feature?  e.g. Something like using 
enctype="application/x-www-form+xml", which is described in the current 
WF2 draft.

[1] http://lists.w3.org/Archives/Public/www-forms/2006Sep/0006

Lachlan Hunt
Received on Wednesday, 6 September 2006 16:58:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC