Re: The form tag

For the first problem I thought that we wouldn't dispatch the events to 
the implicit generated model and implicit submission, but I overlooked the 
repeat construct, and the answer is simply that it is supported sorry 
about that.

And for the second problem, I wasn't aware that we were allowing multiple 
form elements in a single document creating multiple implicit models, also 
my mistake I must have missed that (I thought that it was a single 
container element). 

Thank you for your quick reply and sorry to bug you, with these two simple 
phantom problems,

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 04/28/2008 08:45:32 PM:

> 
> Hi Nick, 
> 
> You raised two problems which don't seem to be problems  for the 
> proposal to use the form tag. 
> 
> 1) Event dispatching problem. 
> 
> Please consider how events are dispatched to content generated by 
> repeat.  An implementation should simply use the same system for 
> dispatching events to implicit model, submission, etc. elements. 
> Moreover, what does this have to do with the use of a form tag? 
> This question is one that arises because we talk about implicit 
> elements that are automatically generated, not because of a tag called 
form. 
> 
> 2) Already have model element. 
> 
> This is the same objection you previously raised, but the email to 
> which you're responding already explains why your objection does not 
apply. 
> At its most streamlined, the 1.2 syntax contains *only* UI controls 
> plus attributes on the UI controls.  The model element does not and 
> should not contain UI controls.  The form element has historically 
> been used to bind together the set of UI controls that correspond to
> a logical data collecting unit.  Why wouldn't we use that? 
> 
> Cheers, 
> 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/28/2008 12:41 AM 
> 
> To
> 
> John Boyer/CanWest/IBM@IBMCA 
> 
> cc
> 
> "Forms WG (new)" <public-forms@w3.org> 
> 
> Subject
> 
> Re: The form tag
> 
> 
> 
> 
> 
> John, 
> 
> Personally I don't see the advantage of having grouping element in 
> XForms, I think a host language can add if it is desirable. And I 
> still have two problems with it... 
> 
> The first problem, is maybe just due the limited knowledge of XML 
> events. But the target of our model related events are all the model
> and children of the model elements (e.g.: submission).  How do you 
> send  events to elements that don't exist in the original document. 
> Or am I wrong in the assumption that our events flow in the original
> document (if it isn't the case don't we have problems that host 
> language 'engine' runs on the original document and XForms runs on a
> cloned and augmented document and therefore the handlers don't have 
> access to the original nodes). 
> 
> The second problem is that in HTML 4.01 you can have multiple form 
> elements in one HTML document, a form-element encapsulates one 
> logical form/'data collecting unit'. In XForms we have a similar 
> concept  a model, this is also represents a logical form/'data 
> collecting unit' (you can not refer to data in another model). 
> Therefore I find it a bit artificial to introduce the form element 
> in XForms which will group together multiple logical forms. 
> 
> 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 
> 
> public-forms-request@w3.org wrote on 04/26/2008 02:54:57 AM:
> 
> > 
> > To keep up the discussion between telecons and hopefully get closure
> > sooner, here is a further attempt to explain why we need it for XForms 
1.2. 
> > 
> > The stream-lined syntax for web authors allows form authors to write
> > UI controls only, with attributes for the things that would normally
> > constitute a model. 
> > 
> > Then, they are able to incrementally add other elements that might 
> > normally appear in a model, on an as-needed basis. 
> > 
> > The form tag would provide a convenient scoping element for logical 
> > MVC units.  The model element cannot be used because it surrounds 
> > model content, not UI.  The group element cannot be used because it 
> > surrounds UI controls, not model content. 
> > 
> > But just as we have needed group for scoping of UI, and we have 
> > needed model for containment of instances, binds and submission, we 
> > now need an element that provides scoping for the whole bundle now 
> > that it can be expressed without easily separable markup. 
> > 
> > The form tag could: 
> > 
> > 1) Consolidate all the internal UI controls and scope them to a 
> > single implied model distinct from models associated with other UI 
> > controls on the page. 
> > 2) Serve as a convenient site for observing processing model events 
> > for the implied model. 
> > 3) Provide a web author friendly means of creating a default 
> > submission for the data implied by the UI controls 
> > 4) Allow incremental adoption of other model elements by scoping the
> > elements to the form tag content 
> > 
> > Finally, assuming one can live with this view of things, the 
> > question arise what to do when the author expresses a model element 
> > within a form tag.  This is where it becomes clear that an expressed
> > model can simply be a nested submodel of the model implied by the form 
tag. 
> > 
> > Cheers, 
> > 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 
> Inventive Designers' Email Disclaimer:http://
> www.inventivedesigners.com/email-disclaimer 

--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer