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

Nick,

I am not sure I find the example you are talking about. You could  
provide it again? Was it done with canonical XForms?

But I should say this: if this is a rare case (I never had to do it  
myself, which, granted, doesn't mean much), then maybe it is not that  
important a use case for the simplified syntax, which IMO is meant to  
address the most common cases. Also remember, the simplified syntax  
does not remove the use of XForms 1.1 as we know it today, or even the  
use or full XPath.

-Erik

On Mar 7, 2008, at 12:40 AM, Nick_Van_den_Bleeken@inventivegroup.com  
wrote:

>
> Erik,
>
> If a variable inside the repeat points to the 'row' value and a  
> variable outside the repeat holds all the values in a nodeset. How  
> do you address what I called the rare cases in my first e-mail  
> (e.g.: sum every item until the current row, compare against  
> previous row, ...)?.
>
> 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/06/2008 07:14:02 PM:
>
> >
> > Nick,
> >
> > It is good that you are raising this. And yes, I think it IS because
> > you are so used to XPath that you like the "nodes" approach ;-)
> >
> > But luckily, you are wrong about the index() function ;-), and  
> this is
> > for two reasons:
> >
> > 1. Using the index() function would give you the wrong result
> >     anyway. What you would need is the current position within the
> >     repeat, not the index (which may turn out to be "1" for all the
> >     iterations, for example). With XPath 2.0, something like this  
> will
> >     work, not sure with XPath 1.0:
> >
> >     <output name="LineTotal"
> >       calculate="$Price[context()/position()]
> >                         * $Quantity[context()/position()]"/>
> >
> >     This said don't even look at the above, it's not necessary  
> anyway
> >     as I explain further below.
> >
> >     But the point is taken, if you had to use the index() or  
> position()
> >     function, it would be a big turn-off. I would not claim that  
> such a
> >     solution satisfies the criterium of "simplicity".
> >
> > 2. More importantly, you WON'T need to use the index() or position()
> >     function!
> >
> >     The implicit binds will look like this (@context,
> >     etc. notwithstanding):
> >
> >       <xf:bind name="order" nodeset="order/row">
> >         <xf:bind name="Product" nodeset="Product"/>
> >         ...
> >
> >     In XForms 1.1, we now clearly define how nested binds are  
> evaluated
> >     within repeats. See "4.7.2 References to Elements within a bind
> >     Element" [1].
> >
> >     This means that from within the repeat, a reference to bind
> >     "Product" will return the node associated with the current
> >     iteration.
> >
> >     If we define XPath variables as simply resolving binds, then  
> you can
> >     just write the following:
> >
> >       <output name="LineTotal" calculate="$Price * $Quantity"/>
> >
> >     and obtain the expected result, without using index() or
> >     position(). We are exactly in the case of section 4.7.2!
> >
> >     From *outside* the repeat, the bind will resolve to the whole
> >     node-set, so you will get all the nodes you expect.
> >
> > In fact, this may turn out to be quite elegant IMO.
> >
> > -Erik
> >
> > [1] http://www.w3.org/TR/xforms11/#idref-resolve-bind
> >
> > On Mar 6, 2008, at 1:23 AM, Nick_Van_den_Bleeken@inventivegroup.com
> > wrote:
> >
> > >
> > > 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/
> >
> >
> 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/

Received on Friday, 7 March 2008 08:51:26 UTC