Re: Pros and cons of different solutions: three slightly different versions of the PO example

I agree with what you've said, Nick, and would *further* point out that 
even in this simple example we would have frustrated an experienced form 
developer who would have had to waste time exploring why his form doesn't 
work because he simply forgot to type a dollar sign somewhere (see the 
LineTotal calculate). 

A proposal that is devoid the requirement to add dollar signs or index 
function invocations or control function invocations is the one that will 
streamline XForms for web authors.  The first proposal I sent is desirable 
*because* it allows the author to not think so much about the distinction 
between the data and the presentational elements.  They name the 
presentational elements, and those names create data, which they can then 
directly reference in their calculations.

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
03/06/2008 01:23 AM

To
Erik Bruchez <ebruchez@orbeon.com>
cc
"Forms WG (new)" <public-forms@w3.org>, public-forms-request@w3.org
Subject
Re: Pros and cons of different solutions: three slightly different 
versions  of the PO example







All, 

Personally I don't have anything against the "control()" XPath  function 
nor the "Variables" approach, but (as mentioned on the call) the 'current' 
syntax becomes really complicated in repeats I think: 

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

Please don't look at the control types nor the attributes that are used 
for calculating the result. The problem that needs to be solved I guess is 
that it is counter intuitive that you need to use the index function to 
address the correct item in the repeat ($Price[index('order')]) because 
you also sometimes want to address all the values the control holds(e.g.: 
sum($LineTotal)). 

It could be that it is just because I use XPath for so long now that I 
find the syntax that just refers to the nodes easier: 

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

I think that the 80%-20% rule will apply here and that in the most cases 
you want to refer to the 'nodes' in the current row and you only want to 
refer to a 'node' in a different row in rare cases (e.g.: sum every item 
until the current row, compare against previous row, ...). So the XPath 
evaluation context we define turns out to be  quite intuitive, also for 
none XPath wizards, I think. 

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 

public-forms-request@w3.org wrote on 03/05/2008 07:46:17 PM:

> All,
> 
> Following our discussion today about simplified syntax and how you
> refer to control values in expressions, I attach 3 different examples
> of a simplified the view of the PO order John sent.
> 
> Note that I have not considered so far the issue of submission or
> insert/delete.
> 
> I think it is primarily important to consider what the code looks like
> to the form author. It has to be easily understandable. After all,
> that is our primary goal in simplification.
> 
> The 3 files look almost entirely the same, except for the way you
> refer to elements. But this has subtle and potentially far-reaching
> implications:
> 
> 1. By referring directly to the implicit data model's nodes
> -----------------------------------------------------------
> 
> The benefit is that it's super-plain XPath. The drawback is that you
> need, as a form author, to be aware of:
> 
> * The implied structure of the underlying data model.
> 
> * "where" you currently are in that model, i.e. a notion of what the
>    current XPath context is.
> 
> So is this too much XPath knowledge to ask from form authors for a
> simplified syntax? For us old-timers it is not that difficult, but for
> simple use cases like John's PO it is disappointing to require that
> much from the form author.
> 
> 2. By using a "control()" XPath function
> ----------------------------------------
> 
> This functions allows referring to the value associated with the
> control, specified by name (or id, see below). Note that I say
> "associated", which means that it could be the actual value of the
> control, or it could be pointing to instance data through implicit
> binds. The point is that it doesn't matter much as we define what
> "control()" means.
> 
> Note that control() could return a node-set (or even a sequence of
> values in XPath 2.0) when the control is within a repeat. This allows
> the sum() function to work as expected.
> 
> The big benefit is that you don't worry about the current XPath
> context anymore. It is unambiguous to which control you are referring
> to, assuming you use unique control names.
> 
> This would be easier to enforce if we actually referred to the control
> by id instead of name. In HTML, there is a distinction between the two
> though, where the id is, well, the id of the element, and the name
> defines something in the data model (name/value in HTML, element name
> in XForms). But it is a pain to have to define a name AND an
> id. Anyway, this is probably something that can be figured out.
> 
> 3. By using XPath variables
> ---------------------------
> 
> The use of variables (i.e. the $foo syntax) has the same benefits as
> the "control()" function.
> 
> The benefit over the "control()" function is that the syntax is
> simpler, and you use a well-understood XPath construct instead of a
> custom function.
> 
> Here my main worry is that of scoping and future-proofing. It is
> important IMO that we do not mess up how we use XPath variables in
> order to leave open the specification of locally-scoped variables in
> the future.
> 
> But:
> 
> * IF <xf:input name="foo"> implies an <xf:bind>
> * AND that <xf:bind> is considered in scope where the variable is used
> 
> THEN the scoping rule becomes palatable. Certainly, it will be if you
> look at the corresponding canonical XForms.
> 
> But this still raises a few questions:
> 
> Q1: When writing canonical XForms, do binds in a model always define
>      XPath variables, and if so, do they expose them by id?
> 
> The issue here is that ids are global in a document, while currently
> in XForms models are scoped with the @model attribute. If you don't
> use an id, then you can have variables with the same name defined in
> multiple models. This enhances reusability.
> 
> In most languages, variables can be scoped in a similar way. The same
> I think would be desirable for XForms, therefore using global ids to
> expose variable names is a serious drawback IMO (even though
> currently, binds are exposed this way).
> 
> Do we need to introduce <xforms:bind name="foo"> ?
> 
> Q2: Do we want to call our future "variables" "binds" instead?
> 
> I like the idea of calling a cat a cat and naming variables
> <xforms:variable>, as this is a notion familiar to every developer on
> the planet and every mainstream programming language has them and
> calls them "variables".
> 
> Binds are familiar to long-time XForms people, but not so much to
> programmers who come from other languages.
> 
> So the day we introduce locally-scoped variables a la eXforms [1],
> will we call them <xforms:variable>, or <xforms:bind>? You know what
> my vote is.
> 
> Q3: Further, a variable in XPath has a name and a value. Binds do not
>      quite work this way.
> 
> Instead, they are currently defined to bind to one or more nodes (and
> possibly, when using the @calculate MIP, assign a value to the
> node(s)).
> 
> This does not quite map in my mind to the notion of a variable
> today. Yes, we can define the behavior of <xforms:bind> as exposing
> the value of the node as the value of the variable, as a node-set for
> example.
> 
> But that is not enough for generalized variables. So how do we get
> there? Certainly, we could modify <xforms:bind> to get closer to the
> XSLT notion of <xforms:variable>, as a holder for any XPath type. But
> then why not introduce <xforms:variable> instead?
> 
> One solution could look like this:
> 
> * Only <xforms:bind> elements having a "name" attribute expose
>    themselves as variables. This solves the issue of scoping by model.
> 
> * We do not extend <xforms:bind> in the future to look more like
>    variables. Instead, we introduce <xforms:variable name="foo"/>. So
>    you can expose variables to XPath either with binds, or with actual
>    variables which are more generic and more author-friendly IMO, when
>    actually used as variables. This is especially important for
>    locally-scoped variables, whether in the model, in the view, or in
>    actions.
> 
> The bottom line for me at this point remains that I still have quite a
> few concerns about the use of the $foo syntax. I believe that we need
> to fully understand the implications of this before going forward with
> this solution.
> 
> BUT if we find a consistent, future-proof solution for the $foo syntax,
> then I would favor it over other solutions because the benefits are
> so appealing.
> 
> -Erik
> 
> [1] http://www.exforms.org/variable.html
> 
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
> 
> 
> 
> 
> --------------------------------
> -----------------
> 
> Inventive Designers' Email Disclaimer:
> 
> http://www.inventivedesigners.com/
> mail-disclaimer
> 
> [attachment "po1.xhtml" deleted by Nick Van den Bleeken/Inventive 
> Group] [attachment "po2.xhtml" deleted by Nick Van den Bleeken/
> Inventive Group] [attachment "po3.xhtml" deleted by Nick Van den 
> Bleeken/Inventive Group] 
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer