Re: Dollar version of simplified syntax still not elaborated for PO example

Hi Nick,

I'm a little confused by your reply. In my example I only used *one* bind
statement, and that was for 'total'. All of the other controls were using
@ref, and that was done deliberately to emphasise just one control being
moved around. In that situation @bind should work exactly as I described,
since the nodeset used is completely independent of the UI evaluation
context:

  "Also, if the Single-Node Binding or Node Set Binding of an element is
expressed with
  the bind attribute, then the resulting node or nodeset is obtained from
the referenced bind
  element. The nodeset attribute of a bind element is evaluated using the
in-scope evaluation
  of the bind element, not the in-scope evaluation context of an element
that references it with
  a bind attribute."

This is how come we get a 'flat model' from the hierarchical model--you can
move a control that uses @bind around in the document to anywhere you like,
and it will still yield the same node from the instance data.

So I'm not sure whether you have added those extra bind statements because
you think I omitted them? And I'm also not sure if you are interpreting the
use of @ref in the controls as actually being @binds?

Sorry if I'm missing something obvious. :)

Regards,

Mark

On 12/03/2008, Nick_Van_den_Bleeken@inventivegroup.com <
Nick_Van_den_Bleeken@inventivegroup.com> wrote:
>
>
> Mark,
>
> I don't believe your example with form controls using the bind attribute
> in the section 'FLAT MODEL V. HIERARCHY: EASIER TO UNDERSTAND' works
> according the XForms spec.
> At least if I read 7.2 Evaluation Context [1] I think you aren't allowed
> to refer to binds that aren't at the same hierarchical level.
>
> So if you have your binds:
>
>  <bind id="total" nodeset="total" calculate="../price * ../qty" />
>   <bind id="shipto" nodeset="shipto">
>      <bind id="street" nodeset="street" />
>      <bind id="city" nodeset="city" />
>   </bind>
>
> You are allowed to write:
>
>   <output ref="total" />
>  will be delivered to
>  <group ref="shipto">
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
>
> But __NOT__:
>
>   <group ref="shipto">
>    Your order of
>    <output bind="total" />
>    will be delivered to
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
> Because the bind 'shipto' can not be referred to inside the 'shipto'
> hierarchical level. If we would allow this we get into trouble with repeats.
>
>
>
> 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
>
> [1] : http://www.w3.org/TR/xforms11/#expr-eval
>
>
>  *"Mark Birbeck" <mark.birbeck@x-port.net>*
> Sent by: public-forms-request@w3.org
>
> 03/12/2008 01:05 PM
>   To
> "Erik Bruchez" <ebruchez@orbeon.com>  cc
> "Forms WG (new)" <public-forms@w3.org>  Subject
> Re: Dollar version of simplified syntax still not elaborated for PO
> example
>
>
>
>
>
>
>
> Hi Erik/John,
>
> I apologise for the delay on commenting on this, and appreciate that
> polite way that John is soliciting feedback. :)
>
> I do agree with pretty much all of Erik's 'workings out' though, so
> what I'd like to do here is focus more on some of the motivations and
> advantages of the dollar syntax. We know there are disadvantages, too,
> of course, but I'll leave those for now, since I want to point out
> that the difference between my proposal (the dollar syntax) and John's
> proposal ('fixing up' the evaluation context) is more than just
> syntax.
>
>
> NAMED VALUES
>
> The essential characteristic of the dollar syntax is that it uses
> 'named values' to attach the UI to data in the model. The key thing is
> not whether we say "$price * $qty" -- any syntax would do -- but what
> is important is that we replace the normal hierarchy that the XPath
> data model imposes, with a 'flat model'.
>
> This is different to John's proposal; he is looking at ways to remove
> the need for ".." in a lot of XPath statements, which is of course a
> worthy goal. But the problem with that is that if you move controls
> around in a form the data they are referring to changes.
>
> The approach I've been touting is not therefore about making XPath
> _slightly_ easier, but about *hiding* the XPath hierarchical model
> altogether, behind a 'flat model'.
>
>
> FLAT MODEL V. HIERARCHY: FORM REUSE
>
> In XForms we already have a way to do a flat model, and that is to use
> bind statements. For example, if we have this data:
>
>  <data>
>    <price />
>    <qty />
>    <total />
>  </data>
>
> we can create a bind statement like this:
>
>  <bind id="total" nodeset="total" calculate="../price * ../qty" />
>
> and then display the total like this:
>
>  <output bind="total">
>    <label>The total for your order is:</label>
>  </output>
>
> This is not only convenient, but is also very good practice. We use it
> a lot in the forms we build for customers, because it means that you
> *really can* separate the model from the view, a crucial consideration
> when reusing parts of a form in other forms.
>
> For example, say I have a new customer that has different data:
>
>  <xyz:order>
>    <xyz:itemprice />
>    <xyz:itemquantity />
>    <xzy:total />
>  </xyz:data>
>
> I can 'hide' this difference simply by changing the bind statement:
>
>  <bind id="total" nodeset="xyz:total" calculate="../xyz:itemprice *
> ../xyz:itemquantity" />
>
> and that means that my UI can stay the same. This may seem small beer
> in a simple example like this, but when you start to create data
> structures based on the Origo schemas, for example, where different
> customers are allowed to add their own parts to the format, then it
> quickly becomes the only way you can build such forms.
>
> So the first reason that 'named values' are good, is because they hide
> the underlying data structure, making reuse easier.
>
>
> FLAT MODEL V. HIERARCHY: EASIER TO UNDERSTAND
>
> However, there is a second reason that mapping a hierarchical data
> structure to a flat one is important, and this reason is more relevant
> here; it's that new users will find it easier to understand.
>
> Returning to our first example, let's add some address information:
>
>  <data>
>    <shipto>...</shipto>
>    <price />
>    <qty />
>    <total />
>  </data>
>
> We'll keep the bind statement to calculate the total:
>
>  <bind id="total" nodeset="total" calculate="../price * ../qty" />
>
> but we won't use it to display the result, and instead we'll use a
> @ref. We'll also show a bit more information to our users when they
> checkout:
>
>  <group ref="shipto">
>    Your order came to
>    <output ref="../total" />
>    and will be delivered to
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
> It's contrived, I agree, but you get the point; the crucial thing to
> grok is that to display the total of the order I have to take into
> account the _position_ of my control in the UI. That seems a little
> odd, in a system that claims to separate the data model from its
> rendering. :) For example, if I move the way the data is displayed,
> like this:
>
>  Your order of
>  <output ref="total" />
>  will be delivered to
>  <group ref="shipto">
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
> you'll see that I had to remove the "../" from the XPath expression.
>
> But if instead I use the 'named value' that represents the total, I
> don't have any of these problems. I can write it like this:
>
>  <group ref="shipto">
>    Your order of
>    <output bind="total" />
>    will be delivered to
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
> or this:
>
>  Your order of
>  <output bind="total" />
>  will be delivered to
>  <group ref="shipto">
>    <output ref="streeet" />, <output ref="city" />, <output ref="zip" />.
>  </group>
>
> and the control that shows the total stays the same either way.
>
> I try to introduce new authors to bind as early as possible, since it
> removes the confusion that invariably occurs when some controls are
> moved around on a form and then the form no longer works. But there is
> also an important philosophical point to be made, which is that just
> because XForms might be using an XML data model, that doesn't mean
> that the UI (or even the middle layer, where bind sits) has to have
> XML structures imposed upon it.
>
> So the second reason that named values are good, is that they make the
> form more 'resilient' to changes at the UI level.
>
>
> ASIDE: LAZY AUTHORING ON BIND STATEMENTS
>
> In formsPlayer we support lazy authoring in bind statements as well as
> UI controls, and I think that is one thing that would need to be added
> to XForms to help with the 'on-ramp'. A form like the following should
> 'just work':
>
>  <bind id="total" nodeset="total" calculate="../price * ../qty" />
>
>  <input ref="price">...</input>
>
>  <input ref="qty">...</input>
>
>  <output bind="total">
>    <label>The total for your order is:</label>
>  </output>
>
>
> NAMED BINDS
>
> Anyway, all of this post is about trying to establish that the key
> part of my 'dollar syntax' proposal was not actually the dollar part.
> :) Whereas in John's proposal he is trying to achieve the 'flatness'
> by making changes to the way evaluation context works, I'm trying to
> achieve the 'flatness' by leveraging the _already existing_ 'flatness
> techniques' that XForms has, i.e., named bind statements.
>
> At the moment in XForms I can only use the nodeset created by a bind
> statement with the bind attribute:
>
>  <output bind="total" />
>
>  <repeat bind="items">
>    ...
>  </repeat>
>
> etc.
>
> It has been proposed in the past that we have a bind function:
>
>  <output ref="bind('total')" />
>
>  <repeat nodeset="bind('items')">
>    ...
>  </repeat>
>
>
> VARIABLES AND DOLLAR SYNTAX
>
> But it's not a big leap to say that a named bind is just the same as
> an XPath variable; we'd then simply make all named binds available as
> a list of variables, i.e., as part of the normal XPath evaluation
> context:
>
>  <output ref="$total" />
>
>  <repeat nodeset="$items">
>    ...
>  </repeat>
>
> and also:
>
>  <output value="$price * $qty" />
>
> This is something I've been keen on for a long time, regardless of
> what we do about the 'on-ramp' for new authors, since it is simple to
> implement, and it is consistent with both the XForms philosophy and
> XPath itself.
>
>
> CONCLUSION
>
> So I'm actually making a combination for proposals:
>
> 1. All named binds become XPath variables, which means that they can
> be referred to using the dollar syntax. I'm in favour of this,
> regardless of whether it's the solution to the on-ramp.
>
> 2. Regardless of whether the first proposal is accepted or not, the
> 'on-ramp' syntax should generate named binds, rather than attempting
> to modify the evaluation context. This means that the UI can be
> rearranged without causing problems for new authors.
>
> The key point, is that even though I'm suggesting that <input name="x"
> /> generates a named bind and a reference to it, that doesn't mean
> that we have to use the 'dollar syntax' to refer to the value; I want
> to stress that my argument for a 'flat model' rather than 'fixing up'
> the evaluation context,  is independent of the syntax used.
>
> I'd like to deal with the syntax itself in a separate post; this post
> is intended to more look at the motivations behind my original
> proposal.
>
> Regards,
>
> Mark
>
>
> On 12/03/2008, Erik Bruchez <ebruchez@orbeon.com> wrote:
> >
> >  John,
> >
> >  I had attached a partial version to my original message:
> >
> >   http://lists.w3.org/Archives/Public/public-forms/2008Mar/0014.html
> >
> >  Namely:
> >
> >
> http://lists.w3.org/Archives/Public/public-forms/2008Mar/att-0014/po3.xhtml
> >
> >  Do you need more?
> >
> >  -Erik
> >
> >
> >  On Mar 11, 2008, at 9:16 PM, John Boyer wrote:
> >
> >  >
> >  > A while ago I posted simplified syntax for the purchase order
> >  > example (except insert/delete triggers for now)
> >  >
> >  > and then the post showed what the corresponding canonical XForms
> >  > would look like.
> >  >
> >  > Then we had a great discussion on the list about various aspects of
> >  > the "dollar" proposal, which seeks to do the same things only by
> >  > using XPath variables based on "implied" binds for named form
> >  > controls.
> >  >
> >  > It definitely seems like both will work.  In fact, the biggest
> >  > oddness may be that many forms will work *whether or not * you use
> >  > the dollar symbols.  I rather hope that only one method or the other
> >  > will work, but that will depend on exactly what canonical XForm is
> >  > implied for the simplified syntax under the dollar (variable)
> >  > proposal.
> >  >
> >  > I like the non-dollar proposal because there are no confusing
> >  > dollars to type, but I like the way that the dollar proposal uses
> >  > the context-based binding ID referencing mechanism to figure out
> >  > which inner bind we might be talking about.  But I'd also like to be
> >  > sure that this claim is actually true in light of some actual markup.
> >  >
> >  > So, for the two reasons above, could someone (prior to the telecon)
> >  > please post the dollar proposal solution to the purchase order
> >  > example given in my prior email here:
> >  >
> >  > http://lists.w3.org/Archives/Public/public-forms/2008Mar/0013.html
> >  >
> >  > Thanks,
> >  > 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
> >  >
> >
> >
> > --
> >  Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> >  http://www.orbeon.com/
> >
> >
> >
>
>
> --
>  Mark Birbeck
>
>  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
>  http://www.x-port.net | http://internet-apps.blogspot.com
>
>  x-port.net Ltd. is registered in England and Wales, number 03730711
>  The registered office is at:
>
>    2nd Floor
>    Titchfield House
>    69-85 Tabernacle Street
>    London
>    EC2A 4RR
>
>
> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
>


-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR