The form tag

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 

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.

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

Blog RSS feed:

Received on Saturday, 26 April 2008 00:56:07 UTC