The Form tag as container, was Re: Continuation of XForms Streamlined for Web Authors

Hi Nick,

Again, I'm splitting up the topics in the hope of having separate threads 
that are easier for people to digest one at a time.

********
On using the form element, I think we need it for the following reasons:

i) As we continue to loosen our syntax to allow instance without model, 
bind without model, submission without model, and implied instances via 
UI, we still need a *container* element that binds everything together.

ii) It is important to use the container element that actually has 
precedence in the web world, and that's "form".  Just as we're asking the 
HTML WG to adopt actual names that have precedence in the XForms 
*Recommendation*, we really need to show that we are willing to do the 
same thing. 

iii) While "submit" might be one way to create an implied submission, I 
still think that we need to have an answer for the *common* syntax that 
today's HTML Forms developers are likely to know about.  It is really no 
sweat to us to *also* say that if you put an action attribute on the form 
tag, then you will get an implied submission.  By the way, I think a 
submit control that expresses no resource would access the submission 
implied by the form tag's action attribute. 

iv) By having an articulated container element, there is a clear place *in 
the DOM* where people can hook events that are targetted at implied models 
and submissions.  They bubble up to the form tag!  This is esp. important 
(to me) for getting access to xforms-submit-done and xforms-submit-error 
on the implied submission, and xforms-ready and 
xforms-model-construct-done on the implied model (for 
initialization/prepopulation work).

v) Having a form container tag allows us to put multiple XForms 1.2 forms 
into different portlets in the same HTML page.

Best Rgards,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





Nick_Van_den_Bleeken@inventivegroup.com 
04/09/2008 12:57 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
Forms WG (new) <public-forms@w3.org>, public-forms-request@w3.org
Subject
Re: Continuation of XForms Streamlined for Web Authors







John/all, 

I included my response in-line. 


public-forms-request@w3.org wrote on 04/09/2008 02:34:13 AM:

> 
> We have a good basis for the streamlined syntax [1] 
> 
> [1] http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html 
> 

I like this simplified syntax because it makes it much easier for new 
authors to learn the language. They can gradually get introduced to more 
advanced features starting from a real simple/short in markup form. It 
also ensures that there aren't two markup syntaxes, a simple syntax for on 
the glass authoring and another syntax for the more advanced stuff, no you 
can mix the new constructs with the ones we now have. In fact we are 
always talking about the simplified syntax and 'Canonical XForms', but as 
I see it there isn't such a clear line. It just happens that we can 
express the simplified syntax, which will be part of the core XForms 
language, in Canonical XForms. This has the advantage for us spec writers 
that we just have to say to which construct it maps, and we don't have to 
worry that much about if we specified all corner cases and that the 
language is clear, because we just have to say that construct-X is mapped 
to construct-Y by .... 

A surplus is that the markup is closely related to the HTML 4.0 markup, 
which makes the jump to XForms for those authors even easier. 
 
> 
> However, there are now follow-up issues to address: 
> 
> 1) What should "implied" submission look like? 
> 
> I think the overall form structure looks like this 
> 
> <form action="some URL" ...> 
> 
>    optional expressed instances 
> 
>    optional expressed submissions 
> 
>    optional expressed binds 
> 
>    all of the above may optionally be wrapped by a model element? 
> 
>    form controls as in [1] above 
> 
> </form> 
> 
> The form tag is needed as the container for the set of things that 
> will be generated into an implied model. 
> 
> The action attribute would imply an XForms replace all submission in
> that model. 
> The implied method should be in accord with the default method for HTML. 

> The implied serialization should be the default for HTML. 
> It should be possible to add the serialization attribute to ask for 
> the XML of the implied instance. 
> 

The proposal of the form-element doesn't, in my opinion, meets the 
requirement of making the syntax easier for a new author. It is just 
making it more complex, an extra element that does almost the same as 
model, but has a different name and is in a different place, and allows 
only one submission URL. 

For "implied" submission I more like the proposal I started working out at 
[A]. Namely allow the attributes/child elements we have on submission 
today on the send action and submit control, and making the submission 
attribute optional. This approach is in line with the approach we took to 
create our "streamlined syntax". 

<submit resource="some URL">
 <label>Submit Timecard</label>
</submit> 

Note: You could even use the deprecated "action" attribute if you wanted. 

Following this approach ensures that there is a smooth transition from the 
syntax you use for "ad hoc" forms and the syntax you use for more advanced 
forms. You can just use the attributes you used on your control/action on 
a submission element that can be reused by several controls/actions. It 
even enables you to define a global submission and override some of the 
properties locally on the control/action where you refer to the global 
submission. 
 
> 
> 2) What will be the relationship between expressed instances and the
> generated instance? 
> 
> I think that you can express all the instances you want, but you get
> a generated instance if you use 'name' attributes in your form controls. 

> If you want to switch from implied instance to expressed instance, 
> then you have to run a converter program on your form. 
> 

I think that for generating an instance there is no difference in using 
the name attribute and the ref attribute. They both support lazy 
authoring, the only difference is that ref changes the in-line evaluation 
context and name doesn't. (Remark, the initial-value attribute should be 
allowed on controls using 'name' and 'ref') 
 
> 3) What is the relationship between expressed model(s) and the implied 
model?
> 
> I think we need to keep the notion of "nested models" in XForms 1.2,
> and we should regard models within form tag as inner models. 
> 

I don't see the need for the concept of nested models for an author that 
is new to the language. And as I doubt that we even need the form-element 
this question isn't that relevant in this perspective.... 
 
> Anything else? 

Personally I think we should focus in making the language easier for new 
authors and making it easy to move to more advanced concepts. If we can 
create constructs that meet the previous requirements and is are a match 
with HTML 4.0 syntax, this is a surplus, but in my personal opinion we 
shouldn't turn the world around, and create a syntax that matches HTML 4.0 
but appears strange to XForms authors. 

> 
> Thanks, 
> John M. Boyer, Ph.D.
> Senior Technical Staff Member
> Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com 
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/
> JohnBoyer?flavor=rssdw 


Regards, 

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com 

[A] 
http://www.w3.org/MarkUp/Forms/wiki/Allow_submission_elements_without_model_element 


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer