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