W3C home > Mailing lists > Public > public-forms@w3.org > April 2008

Need for nested models and model @src, was Re: Continuation of XForms Streamlined for Web Authors

From: John Boyer <boyerj@ca.ibm.com>
Date: Thu, 10 Apr 2008 10:32:43 -0700
To: Nick_Van_den_Bleeken@inventivegroup.com
Cc: Forms WG (new) <public-forms@w3.org>
Message-ID: <OF3D152081.A8CC0B1F-ON88257427.005EEFE1-88257427.006060E8@ca.ibm.com>
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.

*******
Below you point out that nested model is a more *advanced* concept.

Generally, I agree, but only *we* know the model is nested.  It is 
*canonical* XForms that needs the notion of nested models in order to 
allow the streamlined syntax author to express a model within the form 
tag. 

In other words, we want to have more than two new authoring models.  Right 
now, there is only HTML Forms and XForms.  In XForms 1.2 we're creating a 
second authoring model that is as sympathetic as possible to "on the 
glass" HTML forms, and we're adjusting the XForms processing model where 
needed to make that work.  But on-ramp from HTML forms to canonical XForms 
has to contain more than the one data point for "on the glass XForms".

We want authors to be able to say, I like "on the glass XForms" but I now 
realize I need to *express* an extra submission, or an extra instance or 
an extra bind.  Authors should be able to incrementally learn and add this 
stuff as they "grow" into the need for canonical XForms. 

Being able to express additional models that work with an "on the glass 
XForm" is just another logical step as it allows authors to put together a 
"package" of functionality consisting of some instances, binds, 
submissions and actions that work together.

Once we give that capability, we need to be able to offer model with src 
and we need to be able to define it's behavior in terms of nested models 
so that the imported model will work as a part of the system encapsulated 
by the "form" tag.

As a final note, I don't think it is a good idea to assume that HTML 
authors are... unsophisticated.  I.e. it's not a good idea to assume that 
the only thing they will benefit from is the "on the glass" syntax.  We 
also want to be able to reach today's more sophisticated web application 
authors with XForms capabilities.

For example, model with src will be as natural to a web author as script 
with src.  And the "nested model" concept will be as natural as creating a 
"package" of javascript functionality.  Our model tag, with its child 
instance, bind, submission, etc. tags is just a more declarative way of 
setting up a "package" of functionality than is the quirky syntax used for 
creating packages in javascript.

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
Received on Thursday, 10 April 2008 17:34:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:47 UTC