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=rssdwNick_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.compublic-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