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

Re: Form tag(s), implied model(s)and implied submission

From: John Boyer <boyerj@ca.ibm.com>
Date: Sat, 10 May 2008 15:39:56 -0700
To: Nick_Van_den_Bleeken@inventivegroup.com
Cc: "public-forms " <public-forms@w3.org>
Message-ID: <OF186C424C.683A8F54-ON88257445.00797688-88257445.007C81E6@ca.ibm.com>
Mostly goodness below.  A few points to work out:

1) Why is the name attribute not supported?  It seemed like that might be 
a good way to have an ID for the implied model.  On the other hand, you 
could say that if somebody wants to refer to it, then they better express 
the model to give it an ID.  That would be OK with me, I am just curious 
if there is a reason to not support use of name on form.

2) Arent' accept and accept-charset just shorthand for certain header 
settings?  If so, shouldn't those be supported by us, since we can just 
add them to the meaning of the implied submission?

3) I think we need to do the nested model work.  In an earlier email you 
mentioned that you guys wanted to defer nested model for now, and the 
writing below seems to reflect that.  But here's what breaks:

>From below, you're saying that the form tag only implies a model if it 
contains no expressed model.  If it contains an expressed model, then the 
form tag attributes can imply an extra submission within that model.  So 
far so good, but what happens to the implied instance and binds of the 
streamlined markup within the form tag when one adds an expressed model?

To avoid doing nested model work, you could say that the first model still 
gets the implied instance and the extra binds from the streamlined markup. 
 You would have to stipulate that the implied instance would not be the 
first instance of the expressed model because then you would change the 
behavior of the expressed model.  Otherwise, it would work... as far as it 

Now consider the reason why the streamlined XForms author may want to 
express a model within a form tag.  I think the typical reason is that the 
streamlined XForms author will express a model in his form tag is to 
consume a model that contains the machinery for a web service.  So now 
consider that the author wants to consume just two web services.  I think 
the markup will look something like this:

<form name="F" ...>
   <model id="S1" src=".../serviceDefinition1.xfmodel"/>
   <model id="S2" src=".../serviceDefinition2.xfmodel"/>
   <!-- streamlined XForms markup -->

If we take the view that S1 and S2 are both nested within model F, then it 
is easy to see how one could set up an xforms-submit-done listener on S1 
or S2 and then copy data to model F.

If we take the view that the instance and binds implied by F are generated 
within S1, then how do results from S2 ever get into the instance data 
that is driving the user interface in F?

Attempting to answer this question is actually how I got to the conclusion 
that S1 and S2 needed to be the same logical thing, unencumbered by side 
effects of F but able to pull results from F (e.g. on xforms-submit) and 
push results to F (e.g. on xforms-submit-done).  From there, it was a 
short hop to the idea that S1 and S2 would be nested within F and 
therefore have access to F commensurate with that scope.

Hope this helps...

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: 

Sent by: public-forms-request@w3.org
05/09/2008 01:44 AM

"public-forms " <public-forms@w3.org>

Form tag(s), implied model(s)and implied submission


We were a bit under manned on the previous XForms call, but nevertheless 
we decided to make a resolution to add the optional form container element 
to the XForms language. I'm eager to write some spec ready text related to 
"Form tag(s), implied model(s)and implied submission". But just want to be 
sure that the people that couldn't attend the previous call are in line 
with what I felt what the direction on the previous call was.

1) Add a form tag with :
     - required action attribute : Maps to action attribute on a 
     - optional method attribute : Maps to method on submission
     - optional enctype attribute : Maps to serialization  on submission
     - We don't support the following attributes : accept, name, onsubmit, 
onreset, accept-charset 

2) Form element creates an implicit model if no model is present as a 
child. The current model is changed to the first model child of model or 
the implicit model if no model element was present as a child of the form 

3) An implicit submission is added to the 'first' model (can be the 
implied model) of the form element using the attributes on the form 

4) Allow submission attributes on the send and submit elements, the local 
attributes will override the attributes of the referenced submission. When 
no submission is specified the implied submission will be used as a basis.


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


Inventive Designers' Email Disclaimer: 

This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 
Received on Saturday, 10 May 2008 22:40:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:57 UTC