Re: The form tag

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