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

John,

I included my response in-line.

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

John Boyer <boyerj@ca.ibm.com> wrote on 05/11/2008 12:39:56 AM:

> 
> 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.

This can of course be discussed but personally  I don't like name (also in 
XHTML 1.0 spec) to act like id because of a 'restriction' in XML, you can 
only have one attribute of type ID per element (to ensure the uniqueness).

http://www.w3.org/TR/2000/REC-xml-20001006#sec-attribute-types
 
> 
> 
> 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? 

I wasn't sure what to do about those...


> 
> 
> 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 goes. 
> 
> 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 --> 
> </form> 
> 
> 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. 

There are of course good use cases for nested models, not only in the 
streamlined syntax but of course also in Canonical XForms. But at the call 
we were concerned that it would require quite some work to think out all 
the details about nested models, and therefore we thought to keep the 
support for nested models for XForms 2.0.

> 
> 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: http://www.ibm.com/developerworks/blogs/rss/
> JohnBoyer?flavor=rssdw
> 
> 
> 

> 
> Nick_Van_den_Bleeken@inventivegroup.com 
> Sent by: public-forms-request@w3.org 
> 05/09/2008 01:44 AM 
> 
> To
> 
> "public-forms " <public-forms@w3.org> 
> 
> cc
> 
> Subject
> 
> Form tag(s), implied model(s)and implied submission
> 
> 
> 
> 
> 
> All,
> 
> 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 
submission
>     - 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 element
> 
> 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 
element
> 
> 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.
> 
> 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
> 
> [1] http://www.w3.org/MarkUp/Forms/wiki/
> Allow_submission_elements_without_model_element 
> Inventive Designers' Email Disclaimer: http://
> www.inventivedesigners.com/email-disclaimer 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content, and is believed to be clean. 
> -- 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content, and is believed to be clean. 
> -- 
Inventive Designers' Email Disclaimer:   http://www.inventivedesigners.com/email-disclaimer =
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--