Nested binds in future versions of XForms spec

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Nested binds in future versions of XForms spec

claud108
Hi,

I would like to ask if anybody can say something about nested binds in future
versions of XForms spec. Will nested binds exist or not?

I am asking this in the context of these nice refinements of bind element:
http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context


Thank you,
Claudius Teodorescu



Reply | Threaded
Open this post in threaded view
|

Re: Nested binds in future versions of XForms spec

Kurt Cagle-2

Claudius,

Speaking for myself, I know that most of the curent XForms implementation are offering nested binds as extensions, and there are enough advantages to them that I wouldbe very surprised if they did not appear in the 1.2 specification.

There are similarly discussions about defining contextual variables in 1.2, though at this point the working group is really just getting up to speed after the chartering earlier this year. I know that both have been discussed on the futures lists.

Kurt Cagle

On Nov 29, 2010 9:48 AM, "Claudius Teodorescu" <[hidden email]> wrote:
> Hi,
>
> I would like to ask if anybody can say something about nested binds in future
> versions of XForms spec. Will nested binds exist or not?
>
> I am asking this in the context of these nice refinements of bind element:
> http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context
>
>
> Thank you,
> Claudius Teodorescu
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Nested binds in future versions of XForms spec

John Boyer

Hi guys,

Nested binds have been supported in the spec for a very very long time now.
I actually don't recall a time that they were *not* supported, but I do recall several discussions in the fives-yeasr-ago timeframe because
1) implementers were doing it slightly differently, causing subtle differences in the behavior of xpath functions like position()
2) we needed to do some work to define what it meant to make an IDREF to an inner bind whose containing bind's nodeset had size > 1

These were also worked out a long time ago and support appears in XForms 1.0 third edition and XForms 1.1.

I believe Claudius is actually asking when implementers will fully support the "Context Everywhere" feature.  For XForms 1.1, the context attribute is only supported on the insert and delete elements.  Although we really wanted the context attribute in other places, we really had to stop adding things to 1.1, so it was deferred to 1.2.

One of the places where the context attribute would be useful is on inner nested binds, provided the meaning is that it sets the context for evaluating the xpaths but does not change the node to which any MIP expressions apply.  This makes sense on a number of levels, including
1) context should not have special side effects on a particular element like bind; it should just set the eval context for expressions on the element
2) there would be equivalence with alternate markup formats that would make better sense, e.g <bind nodeset="x"> <calculate context=".." value="a+b"/> </bind>

Anyway, I've now created the proper link from the "context everywhere" feature here:
http://www.w3.org/MarkUp/Forms/wiki/@context_everywhere

to the other page about unified eval context that Claudius was reading, because they are about the same thing and because the "context everywhere" feature has the status "Accepted" working group status for XForms 1.2 and has an editor assigned (your truly, in fact).

So, yes, it's coming in the spec sense, and I also believe it is an *easy* one for implementers to get going, so lean on your favorite implementer a bit if you need this sooner rather than later because the implementations lead the spec.

Best regards,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Kurt Cagle <[hidden email]>
To: Claudius Teodorescu <[hidden email]>
Cc: [hidden email]
Date: 11/29/2010 07:07 AM
Subject: Re: Nested binds in future versions of XForms spec





Claudius,

Speaking for myself, I know that most of the curent XForms implementation are offering nested binds as extensions, and there are enough advantages to them that I wouldbe very surprised if they did not appear in the 1.2 specification.

There are similarly discussions about defining contextual variables in 1.2, though at this point the working group is really just getting up to speed after the chartering earlier this year. I know that both have been discussed on the futures lists.

Kurt Cagle

On Nov 29, 2010 9:48 AM, "Claudius Teodorescu" <claud108@...> wrote:
> Hi,
>
> I would like to ask if anybody can say something about nested binds in future
> versions of XForms spec. Will nested binds exist or not?
>
> I am asking this in the context of these nice refinements of bind element:
>
http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context
>
>
> Thank you,
> Claudius Teodorescu
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Nested binds in future versions of XForms spec

claud108
Hi,

Kurt, John, thank you very much for your answers.

Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

Re: Nested binds in future versions of XForms spec

claud108
In reply to this post by claud108
Hi,


I am back with other questions.

On the page about unified evaluation context
(http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context), one can find
the following example:
<bind nodeset="node/a">
    <constraint context=".." operator="and">
          <constraint boolean="b"/>
          <constraint boolean="c"/>
          <constraint operator="or">
                 <constraint boolean="d"/>
                 <constraint boolean="e"/>
         </constraint>
          <constraint operator="not" boolean="f"/>
    </constraint>
</bind>.

This example shows some nice possibilities as to constraints on data.

1. Is the following syntax correct:
<bind nodeset="node/a">
    <constraint context=".." operator="and">
          <constraint boolean="b"/>
          <constraint boolean="c"/>
          <constraint operator="or">
                 <constraint boolean="d"/>
                 <constraint boolean="e"/>
         </constraint>
          <constraint operator="not" boolean="f"/>
    </constraint>
</bind>
<bind nodeset="node/a">
    <relevant context=".." boolean="b"/>
    <readonly context=".." boolean="c"/>
</bind>
<bind nodeset="node/a">
    <relevant context=".." value="b"/>
</bind>,

or should all MIPs grouped as children of a single bind element. I understand
that this future approach allows more MIPs to be applies to a given node, which
the first example shows, but what about the second example above?

2. Theoretically speaking, how depth can one nest binds?

Thank you,
Claudius Teodorescu






Reply | Threaded
Open this post in threaded view
|

Re: Nested binds in future versions of XForms spec

John Boyer

Hi Claudius,

Both theoretically and in practice (as far as I know), binds can be nested as deeply as you like.  There is no limit other than what a form author can reasonably understand or what an application might reasonably demand.  It's the same as asking "how deep can XML elements nest".  They can go as deep as you like, but  XML trees tend to have very high branching factors (i.e. they're not typically very deep at all).

The wiki page you're asking about does contain some additional *suggestions* from me about how we might provide alternative syntax for model item properties.  The working group has not agreed to put these in the 1.2 language at this time.  For example, the working group might go with a user-defined "custom MIP" feature.  Something like this:

<bind nodeset="/root">
   <property name="signed" type="boolean" context=".." value="blah/blah/blah/dsig:SignatureValue != ''"/>
</bind>

One provides the name of the new MIP, its type (boolean, string, maybe number, maybe more stuff for XPath 2.0), and its value.  Maybe other stuff, like how to combine them if there are multiple occurrences.

But with a mechanism like this, then maybe it would be sufficient alternative syntax to use for the currently known MIPs, for example:

<bind nodeset="some/node">
   <property name="calculate" type="string" context=".." value="blah/blah/blah"/>
   <property name="relevant" type="boolean" context=".." value="abc = 'xyz'"/>
</bind>

Perhaps an argument for named MIP elements like calculate and relevant, in addition to property, would be that we could set clever defaults for certain attributes.  For example, in my prior suggestion I used the attribute name (value or boolean) to indicate the type of result I wanted.  But if 'value' were always used, and instead you had a 'type' attribute as is done for the property tag above, then we could potentially give it a tag-specific default, so that the markup would look like this:

<bind nodeset="some/node">
   <calculate context=".." value="blah/blah/blah"/>
   <relevant context=".." value="abc = 'xyz'"/>
</bind>

The type attribute is not specified on the above calculate and relevant tags because the defaults are set appropriate.

Again, neither of the above are yet on the 1.2 plan, but if anything makes it to 1.2, I would guess it would be the property tag and *not* the other tags because this maximizes the benefit to cost ratio.  

And furthermore, suppose we had the property tag and were debating whether to also add calculate, relevant, etc.  Well, frankly, I'd rather see us first solve the issue that you had to add the context attribute to each property.  Maybe it is as simple as below:

<bind nodeset="some/node">
   <property context="..">
      <property name="calculate" type="string" value="blah/blah/blah"/>
      <property name="relevant" type="boolean" value="abc = 'xyz'"/>
   </property>
</bind>

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Claudius Teodorescu <[hidden email]>
To: [hidden email]
Date: 12/02/2010 11:32 AM
Subject: Re: Nested binds in future versions of XForms spec





Hi,


I am back with other questions.

On the page about unified evaluation context
(
http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context), one can find
the following example:
<bind nodeset="node/a">
   <constraint context=".." operator="and">
         <constraint boolean="b"/>
         <constraint boolean="c"/>
         <constraint operator="or">
                <constraint boolean="d"/>
                <constraint boolean="e"/>
        </constraint>
         <constraint operator="not" boolean="f"/>
   </constraint>
</bind>.

This example shows some nice possibilities as to constraints on data.

1. Is the following syntax correct:
<bind nodeset="node/a">
   <constraint context=".." operator="and">
         <constraint boolean="b"/>
         <constraint boolean="c"/>
         <constraint operator="or">
                <constraint boolean="d"/>
                <constraint boolean="e"/>
        </constraint>
         <constraint operator="not" boolean="f"/>
   </constraint>
</bind>
<bind nodeset="node/a">
   <relevant context=".." boolean="b"/>
   <readonly context=".." boolean="c"/>
</bind>
<bind nodeset="node/a">
   <relevant context=".." value="b"/>
</bind>,

or should all MIPs grouped as children of a single bind element. I understand
that this future approach allows more MIPs to be applies to a given node, which
the first example shows, but what about the second example above?

2. Theoretically speaking, how depth can one nest binds?

Thank you,
Claudius Teodorescu