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

Hi Erik,

To your first point, no I think it will not behave correctly-- if we are 
thinking of the same data model.  The absence of the dollar on the 
Quantity subexpression causes it to bind to the single data node of the 
current row *and then* the predicate is applied to attempt to choose the 
Kth node of the nodeset matched by Quantity, but because there is no 
dollar, the Quantity subexpression only matches one node, so the predicate 
causes an empty nodeset to occur on rows other than the first.

To your second point, as I wrote, it did occur to me that we could "make 
the variable/dollar method work too-- for more complex cases".  But the 
sequence of thoughts that happened next were:

1) the dollar method is more... costly... because it inflexibly breaks as 
soon as you don't type those seemingly unnecessary dollars, so it should 
not be the primary method

2) If the primary method is devoid of dollars, then when would I tell 
someone to use it?  Wait a minute, aren't these more complex cases 
supposed to be part of the on-ramp to canonical XForms?  If we build a 
second notation into the simplified syntax, we will confuse people with 
when they have to know about a second notation AND we will confuse them 
further by giving them a third notation to use when the second notation 
doesn't cut it anymore.

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
03/06/2008 10:19 AM

To
"Forms WG (new)" <public-forms@w3.org>
cc

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







John,

See my response to Nick. If I am correct, then the objection that the 
developer will be frustrated because things don't work as expected 
doesn't stand.

It seems that on the contrary, things will work more "as expected" 
with variables than without, at least in the PO example.

Also, note that using variables does *not* preclude the form author to 
use XPath expression *without* variables, in case more complex cases 
must be handled.

-Erik

On Mar 6, 2008, at 9:17 AM, John Boyer wrote:

>
> 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
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/