Re: Re[2]: Nodeset bug and nested setvalue in a repeat. (2 of 2)

Although I agree with Peter that we can't just up and change the 
evaluation context of attributes like value without making any syntactic 
change, I have to agree with Ivan that this is probably now the biggest 
outstanding wrong choice in XForms now.

We've done a lot of work to get to the point of this being the biggest 
elephant in the room, so to speak, but the context setting for these 
attributes is very inconvenient, and we just keep living with a 
proliferation of double dots.

This issue even came up again at the last face to face in a break-time 
conversation between David, Steven and me.  David mentioned at the time 
that there was a problem, which he briefly described, and our break time 
ended before I could get back around to claiming that the problem he 
mentioned did not exist (or perhaps I misunderstood him).  So it would 
help this conversation for David to raise the issue on this thread so we 
can double-check.

But to be clear, the problem is a lot wider than just an issue with 
setvalue.

Here is a simple calculate that has to add two values:

<bind nodeset="c" calculate="../a + ../b"/>

To inject a little humour, for everybody else in the world 2+2 is 4, but 
for us it's got to be dot-dot-2 + dot-dot-2 to get 4?!?

One gets the niggling suspicion that we took a wrong turn on this point, 
as is often signaled by authoring inconvenience.  But the "setvalue in 
repeat" problem that Peter raised makes it clear that the suspicion is 
justified.  It is easy to see, as Ivan points out, that the bug would not 
exist if @value took the same starting context as @ref in setvalue, just 
as the dot-dot proliferation would not occur in calculate if it took the 
same evaluation context as the nodeset attribute in bind.

The key issue in both cases is being able to understand that one is 
setting up a formula or value or what have you for a node without needing 
to use *that* node as the starting context for the formula or value.

We really do want to get to the nirvana of evalation context that Ivan is 
describing, so how do we do that without breaking existing forms and 
without being a nuisance to forms authors? 

I couldn't say what to name it, but maybe another attribute on the default 
model would do the trick.  Something like unifiedcontext= "true|false". 
The true setting would say that all attributes of an element are evaluated 
with the in-scope evaluation context (i.e. the result of @context, if it 
appears, or the default otherwise). The true setting could even be the 
default for 1.1, and the false setting could be the default for 1.0 forms.

So, Ivan, note that the XForms 1.1 last call period is extended until the 
end of April.  Last call is exactly the best time to report these problems 
and proposing a roughed-out solution like a controller attribute that 
allows us to get the new and better behavior.  So, why don't you take a 
crack at sending something like this as an email to www-forms-editor as 
1.1 last call feedback?  After all, this really is more than just a 
nuisance.

John M. Boyer, Ph.D.
STSM: 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





Ivan Latysh <IvanLatysh@yahoo.ca> 
Sent by: www-forms-request@w3.org
04/13/2007 05:34 PM
Please respond to
Ivan Latysh <IvanLatysh@yahoo.ca>


To
www-forms@w3.org
cc

Subject
Re[2]: Nodeset bug and nested setvalue in a repeat. (2 of 2)







Hello Peter,

Friday, April 13, 2007, 7:46:03 PM, you wrote:

> Thanks Ivan for the comments.
> The issue with this one is that the 1.0 spec for XForms is a published
> specification.
> I have close to 150 forms in production with many clients that use the
> setvalue in repeats, and outside of repeats.  All of them are using the
> 1.0 rule.  Across all of the other adopters of XForms there are probably
> several thousand forms so changing the rules is not an option.  Anything
> has to add-to the spec, not change it.  There is room for clarification
> where the spec is ambiguous but in this case I don't think it is.
As you just proved my point - it is still manageable.
This issues is fundamental issue and all actions and components has to be
updated with clear definition of the context/scope.

Covering it up, will bring dozen maybe hundreds more severe issues, as 
soon
XForms began adopting more widely. And you will see how forked XForms 
projects
start popping up as a mushrooms after the rainy day. There are enough 
powerful
developers that will not tolerate flaws in the specs, they will choose 
their own path.
So it is the right thing to do to fix it while it is manageable.

If you still belive that I am wrong let's see is there are any use cases 
that
won't work after spec changed ?
D.u. have any examples that will fail ?

-- 
Best regards,
 Ivan                            mailto:IvanLatysh@yahoo.ca