- From: John Boyer <boyerj@ca.ibm.com>
- Date: Thu, 15 May 2008 15:25:59 -0700
- To: Nick_Van_den_Bleeken@inventivegroup.com
- Cc: public-forms@w3.org
- Message-ID: <OF2A95E52A.9FB69FA1-ON8825744A.00770319-8825744A.007B3ACF@ca.ibm.com>
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 invocations. 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. 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 Nick_Van_den_Bleeken@inventivegroup.com Sent by: public-forms-request@w3.org 05/15/2008 08:50 AM To public-forms@w3.org cc Subject what happens if someone puts a model inside a form tag? All, 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" constraint="is-card-number(.)"/> ... </model> ... <!-- streamlined XForms markup --> </form> 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. Example: <form name="F" ...> ... <model id="S1"> ... <bind nodeset="number" type="card-number" constraint="is-card-number(.)"/> <submission id="advanced-search" resource=" http://example.com/search" method="post" ... /> ... </model> ... <input ref="number" readonly="true()"> <label>Credit card number</label> </input> <submit submission="search"> <label>Search...</label> </submit> </form> is 'transformed' to <form name="F" ...> ... <model id="S1"> ... <bind nodeset="number" type="card-number" constraint="is-card-number(.)"/> <bind nodeset="number" type="card-number" readonly="true()" /> <submission id="search" resource="http://example.com/search" method="post" ... /> ... </model> ... <input ref="number" > <label>Credit card number</label> </input> <submit submission="search"> <label>Search...</label> </submit> </form> 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 -- 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