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

Received on Wednesday, 12 March 2008 12:12:50 UTC