Using name attribute instead of ref, 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 your point about there being no difference between using name and using 
ref, there are quite a few differences actually:

i) Using 'name' means we have provided a means for *current HTML practice* 
to be interpreted by XForms.  We really need to be as accommodating as we 
possibly can for the precedence of HTML on the web.

ii) Using 'name'  implies generation of named binds, not just instance 
data.  The named binds are used as variables in expressions, and there is 
an interesting means of determining the value of the variables based on 
context.

iii) Using 'name' implies an important context shift for the expressions 
in calculate, relevant, readonly, etc. that are added to controls but 
moved to the named binds.

iv) Using 'name' implies a 'bind' attribute on the control, not a ref 
attribute.

v) Using 'name' on a repeat has very special behavior.  It implies 
creation of a prototypical instance, not just hierarchy in the default 
implied instance

Best regards,
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