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