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

Re: XForms 1.2 Simplified Syntax Proposal

From: Ulrich Nicolas Lissť <unl@dreamlab.net>
Date: Wed, 02 Apr 2008 16:31:26 +0200
Message-ID: <47F398BE.50601@dreamlab.net>
To: John Boyer <boyerj@ca.ibm.com>
CC: public-forms@w3.org

Hi John,

thanks for clear and concise proposal. However, I still have my problems 
with the variable concept introduced by the dollar syntax:

a) If we introduce such a variable concept in simplified syntax, users 
and authors will ask for first class variables in normal XForms syntax. 
We already have the Future Feature "Variables in XPath" [1], which 
should be considered in this context in order not to create 
inconsistencies between two possibly differing variable concepts.
b) I consider the dollar-syntax as pure syntactic sugar. While syntactic 
sugar is a Good Thing in some cases (enhanced readability, easier 
processing and the like), I think in this case it should be avoided due 
to a).

I'd like to propose a dollar-free syntax. The simple purchase order form 
would look like this in simplified syntax:

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

Note that this is exactly the same like your proposal in 3) except for 
the dollar signs. This has following implications:

1) The bind part of the canonical form would be generated as:

<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"/>
     </bind>
</bind>
<bind id="Subtotal" nodeset="Subtotal">
     <calculate context=".." value="sum(row/LineTotal)"/>
</bind>
<bind id="Tax" nodeset="Tax">
     <calculate context=".." value="Subtotal * 0.07"/>
</bind>
<bind id="Total" nodeset="Total">
     <calculate context=".." value="Subtotal + Tax"/>
</bind>

In addition to 5a) of your proposal this means that all calculated 
expressions of named controls have to be analyzed and to be transformed 
into XPath expressions matching the generated data structure. This could 
  easily be done by static analysis. The need to do so is simply 
signaled by the presence of @name.

2) Changes to the processing model 5b) through 5d) of your proposal 
would not be necessary. No need to adjust rebuild logic, no need to 
cache (name, context, bind) triples. Changes 5e) and 5f) of course remain.

I hope this makes sense. What do you think?

Regards,
Uli.

[1] http://www.w3.org/MarkUp/Forms/wiki/Variables_in_XPath

John Boyer wrote:
> 
> 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"/>
> </repeat>
> <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"/>
> </repeat>
> <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 
> expressions.
> 
> 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:
> 
> <model>
>   <instance id="default">
>     <data xmlns="">
>       <row>
>          <Product>...
>          <Price>...
>          <Quantity>...
>          <LineTotal>...
>       </row>
>       <row>
>          <Product>...
>          <Price>...
>          <Quantity>...
>          <LineTotal>...
>       </row>
>       <Subtotal>...
>       <Tax>...
>       <LineTotal>...
>     </data>
>   </instance>
> 
>   <instance id="row_template">
>       <row xmlns="">
>          <Product></Product>
>          <Price>0.00</Price>
>          <Quantity>0</Quantity>
>          <LineTotal></LineTotal>
>       </row>
>   </instance>
>  
>   <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 * 
> $Quantity"/>
>     </bind>
>   </bind>
>   <bind id="Subtotal" nodeset="Subtotal">
>      <calculate context=".." value="sum(row/LineTotal)" or 
> "sum($LineTotal)"/>
>   </bind>
>   <bind id="Tax" nodeset="Tax">
>      <calculate context=".." value="Subtotal * 0.07" or "$Subtotal * 
> 0.07"/>  
>   </bind>
>   <bind id="Total" nodeset="Total">
>      <calculate context=".." value="Subtotal + Tax" or "$Subtotal + $Tax"/>
>   </bind>
> </model>
> 
> <repeat bind="row">
>     <select1 bind="Product"> ...
>     <input bind="Price"> ...
>     <input bind="Quantity"> ...
>     <output bind="LineTotal"/>
> </repeat>
> <output bind="Subtotal"/>
> <output bind="Tax"/>
> <output bind="Total"/>
> 
> <trigger>
>     <label>...</label>
>     <insert ev:event="DOMActivate" context="." bind="row" 
> at="index('row')" position="after" origin="instance('row_template')"/>
> </trigger>
> <trigger>
>    <label>...</label>
>    <delete bind="row" at="index('row')"/>
> </trigger>
> 
> 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.
> 
> 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
> 

-- 
Ulrich Nicolas Lissť
Received on Wednesday, 2 April 2008 14:32:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:47 UTC