- 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 To John Boyer/CanWest/IBM@IBMCA cc public-appformats@w3.org, www-forms@w3.org Subject 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 appears: > > <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 http://lachy.id.au/
Received on Wednesday, 6 September 2006 16:58:08 UTC