W3C home > Mailing lists > Public > public-forms@w3.org > March 2008

XForms 1.2 Simplified Syntax Proposal

From: John Boyer <boyerj@ca.ibm.com>
Date: Thu, 27 Mar 2008 16:51:35 -0700
To: public-forms@w3.org
Message-ID: <OF267F8C24.CF805245-ON88257419.007186CD-88257419.00831214@ca.ibm.com>
To summarize the XForms 1.2 Simplified Syntax Proposal (so far):

1) An "on the glass" syntax in which name attributes and UI hierarchy are 
used to imply an underlying data structure.

2) The implied data structure will mean that the data names are directly 
referenceable in calculations without an author having to understand any 
complicated XPath.  If the author must refer to something that is not at 
the same logical level in the UI hierarchy, then a simple slash-based 
addressing scheme suffices.  This is still not any complicated XPath to 
understand.  It means that someone could write a simple purchase order 
using syntax that looks like this:

<repeat name="row"> 
    <select1 name="Product"> ... 
    <input name="Price" type="decimal" default="0.00"> ... 
    <input name="Quantity" type="integer" default="0"> ... 
    <output name="LineTotal" calculate="Price * Quantity"/> 
<output name="Subtotal" calculate="sum(row/LineTotal)"/> 
<output name="Tax" calculate="Subtotal * 0.07"/> 
<output name="Total" calculate="Subtotal + Tax"/> 

3) The name attributes and UI hierarchy will also imply a matching set of 
hierarchic "bind" elements is id and nodeset attributes whose values match 
the name.  The binds will be addressable in calculation expressions using 
a simple "variable" concept in which the name is preceded by a dollar 
sign.  It means that someone could also write the simple purchase order by 
doing this:

<repeat name="row"> 
    <select1 name="Product"> ... 
    <input name="Price"> ... 
    <input name="Quantity"> ... 
    <output name="LineTotal" calculate="$Price * $Quantity"/> 
<output name="Subtotal" calculate="sum($LineTotal)"/> 
<output name="Tax" calculate="$Subtotal * 0.07"/> 
<output name="Total" calculate="$Subtotal + $Tax"/> 

4) The simplified syntax for triggering "insert row" and "delete row" are 
yet to be worked out, but I suspect from the HTML perspective, someone 
would add a button whose "onclick" would use the updated IDL interface we 
will be doing to call insert and delete and setvalue actions via script. 
In HTML, it might look something like this:

<button ... onclick="insert('row')" ... >
<button ... onclick="delete('row')" ... >

The simplicity here is coming from selection of the best defaults for 
insert and by also assuming that the occurrence of repeat will result in a 
template instance being created with an ID that is based on the repeat 
name.  So the defaults for insert should be position="after" 
at="index('row')" and origin="instance('row_template')" and context=".". 
Note that in all places where I used the word "row", substitute whatever 
the name attribute value from the repeat.

5) There are some XForms processing model updates that will be needed to 
allow the above to be seamlessly mapped to canonical XForms:

a) We need to add MIP child elements to bind that allow us to set the 
context to ".." and re-use the same expression as the simplified syntax. 
This is another way of saying that, for simplified syntax, the calculate 
style expressions take the in-scope eval context node and the context of 
the expression.

b) The nodesets of identified binds are available as variables to all 
XPath expressions *except* the nodeset attribute of bind elements.

c) The processing model for rebuild is defined to consist of a first pass 
to resolve all bind nodesets then a second pass to evaluate MIP 

d) The nodeset associated with a variable reference is decided based on 
the variable name and the context node for the XPath expression.    This 
allows us to select the correct occurrence of an inner bind whose nodeset 
must be returned.  However, sometimes it will be the union of nodesets 
from multiple inner binds if the context node is associated with a 
containing ancestor bind.  Implementations should be able to cache these 
(name, context, nodeset) tuples between rebuilds.

e) MIP attributes at the UI level are converted to MIP statements within 
the generated binds. 

f) Aside from implying a data layer and bind layer, the name attributes in 
the UI components also imply UI bindings to the bind layer.  In the case 
of the name on repeat, an extra empty template instance is also implied 
for use by insert.

Based on these adjustments to the normal semantics of XForms, both 
simplified syntax lists above would correspond to the following 
"canonical" XForm:

  <instance id="default"> 
    <data xmlns=""> 

  <instance id="row_template"> 
      <row xmlns=""> 
  <bind id="row" nodeset="row"> 
    <bind id="Product" nodeset="Product"/> 
    <bind id="Price" nodeset="Price" type="decimal"/> 
    <bind id="Quantity" nodeset="Quantity" type="integer"/> 
    <bind id="LineTotal" nodeset="LineTotal">
       <calculate context=".." value="Price * Quantity" or "$Price * 
  <bind id="Subtotal" nodeset="Subtotal">
     <calculate context=".." value="sum(row/LineTotal)" or 
  <bind id="Tax" nodeset="Tax">
     <calculate context=".." value="Subtotal * 0.07" or "$Subtotal * 
  <bind id="Total" nodeset="Total">
     <calculate context=".." value="Subtotal + Tax" or "$Subtotal + 

<repeat bind="row"> 
    <select1 bind="Product"> ... 
    <input bind="Price"> ... 
    <input bind="Quantity"> ... 
    <output bind="LineTotal"/> 
<output bind="Subtotal"/>
<output bind="Tax"/> 
<output bind="Total"/> 

    <insert ev:event="DOMActivate" context="." bind="row" 
at="index('row')" position="after" origin="instance('row_template')"/>
   <delete bind="row" at="index('row')"/>

6) The final piece is the submission, which we think is just implied from 
the HTML form element's attributes, except we need to talk about how to 
trigger XML submission versus tag-value pairs.  Still a bit more work 
needed here to nail it down at the same level of precision as the above.

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: 
Received on Thursday, 27 March 2008 23:52:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:29 UTC