Re: what happens if someone puts a model inside a form tag?

Hi Nick,

Thanks for the great summary of the issue.

I like the third option best, which is the one in which the content of the 
"implied" model is merged into the first explicit model. 

I think it is reasonable to say that a single form tag should not have 
more than one model element child.

Because we deferred not only nested models but, more importantly, we 
deferred putting src on model, this means that of someone wants to invoke 
web services, then they *must* express a model.  If they want to use N web 
services, then they express *one* model with the N web service submissions 
within it.  They should be able to do this without rewriting the whole 
stream-lined syntax form that they might have developed before deciding to 
embellish with web services.

As you mentioned, this approach will mean that we have to modify the 
condition under which "lazy authoring" occurs.  Right now we say that lazy 
authoring occurs if you have a model with no instances in it, but this 
forces a form author to write an explicit data instance as soon as they 
want to also have instances for the SOAP envelopes of their web services. 
Yet, the use of the *name* attribute on UI controls gives us an 
alternative way of detecting that we need an implicit instance even if the 
model contains other instances.

Next, once we decide that the implicit instance should be generated, it 
should be clear that it should still be the default instance because 
expressions in the streamlined syntax won't contain 'instance' function 

Next, this means that an explicit model either cannot have its own default 
instance or it must have a way of declaring the default instance, which 
would then shut off the implicit "lazy authored" instance. 

A few months ago, I had proposed some ideas for indicating the default 
instance by omitting the 'id' attribute.  At the time, Steven found that 
to be uncomfortable because there are lots of XForms where the first 
instance has an 'id' but the first (declared) instance is still the 
default.  So, I think we cannot make a change to the "canonical" XForms 
processing here.

Instead, it seems we should be considering how explicit models are written 
by streamlined syntax authors. 

If the form author uses the name attribute on UI controls, then the author 
is requested an implied default instance, so if the same author expresses 
a model, he should expect that all of his expressed instances would *not* 
be the default.  This means he will have to put an 'id' on every expressed 
instance in order to access its content, and any references to the 
expressed instances will need to invoke the instance() function.

If the form author does not use name attributes on UI controls and the 
form author expresses a model, then they get the current lazy authoring 
behavior, i.e. an implied instance if the model contains zero instances, 
and no implied instance otherwise.

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: 
Sent by:
05/15/2008 08:50 AM


what happens if someone puts a model inside a form tag?


We have to decide what it means when a user adds an explicit model inside 
a form wrapper element :

<form name="F" ...>
  <model id="S1">
        <bind nodeset="number" type="card-number" 
  <!-- streamlined XForms markup -->

We decided yesterday that we are going to postpone nested models to XForms 
2.0 (as original planned and because of the work that is required on how 
we are going to support nested models in XForms). 
Therefore I see three possible solutions:

1. The implicit model created by the form element is a separate model  and 
the example form above has two separate models in its canonical XForms 
representation. This has the disadvantage that there is no possible to 
transfer data from one model to the other without doing submissions to the 
server (I know you can do it through scripting but this is hack/bug)

2. The explicit model replaces the implicit model. There is only one model 
so no inter model communication is necessary. But this has the 
disadvantage that all the MIPs and default values that are specified on 
the UI controls are lost.

3. The implicit model is merged with the first explicit model. This has 
the advantage that you can specify MIPs and default values on the 
UI-controls and use binds, submissions in the model for more advanced 
constructs (applying MIPs to all nodes with a certain name, define the 
submission parameters only once and reuse them in multiple 
submit-controls,...). We could even specify that the default values on the 
controls override the defaults in the default instance, this will require 
some modification to the current lazy authoring specification but they can 
be done locally and easily.


<form name="F" ...>
  <model id="S1">
        <bind nodeset="number" type="card-number" 

        <submission id="advanced-search" resource="" method="post" ... />
  <input ref="number" readonly="true()">
        <label>Credit card number</label>

   <submit submission="search">


is 'transformed' to

<form name="F" ...>
  <model id="S1">
        <bind nodeset="number" type="card-number" 
        <bind nodeset="number" type="card-number" readonly="true()" />

        <submission id="search" resource="" 
method="post" ... />
  <input ref="number" >
        <label>Credit card number</label>

   <submit submission="search">


Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Inventive Designers' Email Disclaimer:

This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 

Received on Thursday, 15 May 2008 22:26:45 UTC