Re: The Form tag as container, was Re: Continuation of XForms Streamlined for Web Authors

Hi John,

I included my response in-line


John Boyer <boyerj@ca.ibm.com> wrote on 04/10/2008 07:16:52 PM:

> 
> Hi Nick, 
> 
> Again, I'm splitting up the topics in the hope of having separate 
> threads that are easier for people to digest one at a time. 
> 
> ******** 
> On using the form element, I think we need it for the following reasons: 

> 
> i) As we continue to loosen our syntax to allow instance without 
> model, bind without model, submission without model, and implied 
> instances via UI, we still need a *container* element that binds 
> everything together.

I don't see the point of making the model optional, if we 'invent' a new 
element that becomes required and has the same semantics as a model. I 
personally don't see the advantage of this, it will only confuse form 
authors, when do we need the 'model' element, when the 'form' element and 
when the 'xyz' element (with 'xyz' an element we add in a future release 
because we want to make 'form' optional)?
 
> 
> ii) It is important to use the container element that actually has 
> precedence in the web world, and that's "form".  Just as we're 
> asking the HTML WG to adopt actual names that have precedence in the
> XForms *Recommendation*, we really need to show that we are willing 
> to do the same thing. 

I know that it isn't a standard, but in all the AJAX toolkits they are 
inventing lots of new attributes (validation, currency, formatting, 
representation) so I don't why they couldn't learn a new element model 
when they start to create more advanced forms. The XForms WG has made the 
decision a long time ago that the building block for an application is a 
model, and didn't wanted to preserve the element name form. Personally I 
don't think we should adopt the old element name after releasing 2 
versions of the language (it is just going to confuse people, see first 
answer). 

> 
> iii) While "submit" might be one way to create an implied 
> submission, I still think that we need to have an answer for the 
> *common* syntax that today's HTML Forms developers are likely to 
> know about.  It is really no sweat to us to *also* say that if you 
> put an action attribute on the form tag, then you will get an 
> implied submission.  By the way, I think a submit control that 
> expresses no resource would access the submission implied by the 
> form tag's action attribute.

I agree that it is a no-brainer for us implementers to add this feature, 
but I don't think we should add this to the language. I keep repeating 
myself, but it just feels like polluting our syntax.
 
> 
> iv) By having an articulated container element, there is a clear 
> place *in the DOM* where people can hook events that are targetted 
> at implied models and submissions.  They bubble up to the form tag! 
> This is esp. important (to me) for getting access to xforms-submit-
> done and xforms-submit-error on the implied submission, and xforms-
> ready and xforms-model-construct-done on the implied model (for 
> initialization/prepopulation work). 

They can just add an empty model element, if they need to hook up event 
handlers, or need access to our new and improved IDL.

> 
> v) Having a form container tag allows us to put multiple XForms 1.2 
> forms into different portlets in the same HTML page. 

Don't we have this functionality already in XForms 1.0 where you can have 
multiple models.



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


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

Inventive Designers' Email Disclaimer:

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