Re: context for origin on xf:insert

Hi David,

I think that the creation of helper actions that simplify the common use 
patterns of insertion and deletion is certainly in keeping with the 
overall 1.2 goal of simplifying authoring, and it seems that one channel 
of info for these should be the better table of "common insert/delete 
tasks" that Uli and I are obligated by action item to create.

I'm particularly fond of the idea of writing the new actions as more 
direct codings of common insert/delete tasks because it eliminates 
confusion over what type of events to dispatch to the instance.  This was 
one issue we had the last time this came up.  It seemed like a 
proliferation of new events would show up rather than just having 
xforms-insert to indicate that a node was added (regardless of how) and 
xforms-delete to indicate that a node was deleted (regardless of which 
action did the deletion).

Regarding the issue of whether or not to generalize the context attribute, 
I hear you.

I've brought it up because generalizing @context has come up in the past 
as a possible way to solve certain problems, such as how to set the 
context for a group without consuming the MIPS associated with the node. 

But, I think perhaps we should consider solving problems like that 
*without* expanding the context attribute beyond its current use in 
insert/delete.  Two reasons. 

First, we already have  a more general form of the problem with ref. There 
are things that use ref which should only consume some or perhaps none of 
the MIPS, e.g. setvalue and message don't seem like they should consume 
MIPs like relevant and readonly, and trigger and group seem like they 
should only consume relevant. 

Second, the conclusion that @context is specific to insert/delete would 
mean that we could leave it as evaluating *after* if and while.  This is 
more comfortable to me (I found the idea of evaluating context before 
if/while to be unnerving, esp. on insert.delete).  It is also more 
compatible with the current version of XML Events 2.0.

Finally, regardless of the outcome of the above, it does seem like 
insert/delete  should use @context regardless of whether the nodeset 
binding is expressed with @nodeset or with @bind.  How do you feel about 
that?

Thanks,
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





David Landwehr <david.landwehr@picoforms.com> 
Sent by: www-forms-request@w3.org
08/14/2007 02:48 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
"Mark Birbeck" <mark.birbeck@formsPlayer.com>, "Aaron Reed" 
<aaronr@us.ibm.com>, www-forms@w3.org
Subject
Re: context for origin on xf:insert






Dear John and working group,

I know you addressed Mark Birbeck and Aaron in your mail but I feel that I 
must reply.

There is no doubt that the added functionality for insert and to some 
degree delete for XForms 1.1 is required to solve the most simple usecases 
which cannot easily be solved in XForms 1.0. As you might all know the 
group first decided to enhance the functionality of insert and delete 
which I did some initial write up for in Cannes some years ago. While I 
was explaining to the group at the F2F what the different attributes meant 
in different scenarios most of the people there looked confused and very 
unhappy. Additional several more points was made which was not covered by 
my write up. Under this meeting Mikko suggested the much simple approach 
to simple make separate actions for each functionality. A decision which I 
was very happy with and lead to the actions destroy and duplicate (actions 
which took me under 1 hour to implement and test). Additional these 
actions provided a clarity  when used in a form because it 
was apparent what was suppose to happen. Also the write up in the 
specification was pretty simply and to my eyes pretty easy to follow.

I have numerous times complained about the removal of destroy and 
duplicate and argued that the new actions were to complicated (just as my 
write up was at Cannes). But since the group don't have a voting practice 
and because members keep bringing closed issues back on the table, then at 
the time I didn't feel up to do the struggle/fighting needed for keeping 
the two actions. I must admit that the write up of the insert action in 
particular is impressive, it solves all problems and provides a lot of 
functionality. Regrettably the action does it on the cost of complexity 
for authors and to some degree implementors (e.g. making sure all corner 
cases are implemented according to the specification).

As last call is over there is not much to do about. But I urge the working 
group members to compare the insert and duplicate action and consider the 
different design approaches for the future versions of the specification:
1) The insert action in XForms 1.1 
http://www.w3.org/TR/xforms11/#action-insert
2) The duplicate action 
http://www.w3.org/TR/2004/WD-xforms11-20041115/#duplicate-action

I would also like to express a desire to the group *not* to make the 
context attribute available everywhere. Context rules are daunting enough 
as it is and adding more context controlling attributes containing XPath 
is not the way to make it easier for authors.

Best regards,
David Landwehr

 


On Aug 14, 2007, at 7:11 AM, John Boyer wrote:


Hi Mark, 

Yes, but what do you think about correcting the actual part that caused 
Aaron's confusion? 

We already resolved for 1.1 to do a better job on the section's examples 
AND to clean up any errors and design misfires that are causing confusions 
and to include in future version of XForms more actions for special types 
of insertions/deletions.  As you are one of the editors of 1.2 and this 
issue seems near and dear, I assume that might impact which future version 
it will be that contains the actions.  I also think it is wholly 
appropriate for XForms 1.2 since the major focus of that release will be 
ease of authoring. 

In the meantime, we are well *past* last call on XForms 1.1, so this issue 
does not impede last call.  Moreover, there is no implementation hurdle 
here, so the issue would block neither entry to nor exit from CR for 1.1. 
 Aaron does not like the design, which is different from it being 
unimplementable. 

In the interest of doing the best possible job, it pays of course to 
examine the exact point of confusion for Aaron, which turns out to be that 
the context attribute is ignored if you use a bind attribute for the 
nodeset binding.  This is a design error that I think happened because we 
have paid more attention to the nodeset version of insert.  The bind 
attribute version is used less often because the bind attribute itself is 
a problem that we can hopefully eventually do away with (a veiled plug for 
a bind function for non-model bindings, by the way).  Not as many people 
use @bind, so its not being perfect didn't seem like the horns end of the 
bull. 

Now that we are looking, though, it is clearer that the context attribute 
should *always* override the in-scope evaluation, not just when a nodeset 
attribute appears.  This is necessary to ensure that the context attribute 
behavior for insert/delete in 1.1 is generalizable to having a context 
attribute available for all elements, which is another thing I know we 
both want to see happen no later than 1.2 

This in turn got me thinking about where the context attribute will go 
when it is generalized.  Of course it will go into the common attributes, 
and it will be described as overriding the in-scope evaluation context 
used for the rest of the element.  From there, it was no big leap to 
realize that context needs to be evaluated before 'if' and before each 
iteration of 'while'.  These are necessary because context is evaluated 
*first* as a common attribute, whereas if and while are specific to 
actions. 

So, finally, I started thinking about how to correct the spec.  The spec 
*could* be corrected by putting special language into a number of sections 
to describe how context goes first.  Or, the spec *could* just put 
@context into the common attribute bundle, along with pretty much the same 
special language about how context goes first.  And my question to the 
group was: Recognizing that my request for the latter approach was turned 
down a year ago, are there any members of the group who think the new 
issue from Aaron is enough new technical information to reopen the 
decision and perhaps support the latter approach? 

That's my sales pitch, and I' sticking to it :-) 
Which do you prefer, Mark? 

Thanks, 
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




"Mark Birbeck" <mark.birbeck@formsPlayer.com> 
Sent by: www-forms-request@w3.org
08/12/2007 01:45 PM 


To
"Aaron Reed" <aaronr@us.ibm.com> 
cc
www-forms@w3.org 
Subject
Re: context for origin on xf:insert









Hi Aaron,

> Insert is a difficult section, to be sure, but I'd rather 1.1 get
> finalized and out the door rather than bogging down too much more.  If
> it is truly broken, then sure it is better to fix it now than later.
> Maybe that is really the case.  But perhaps all we need is a companion
> article posted/linked to across different XForms-based sites that has a
> LOT of examples and explains things in plain speak rather than spec
> language.  Something that is proof read and endorsed by the WG as being
> 'correct'.  Or it might be as simple as getting the 1.1 insert testsuite
> testcases out there early and making sure that they get an extra review
> and approved by the WG as being 'correct'.

I see what you're saying, but the problem with that approach is that
if people are saying that insert is too complicated _now_, then the
possibility of an issue being raised at Last Call is surely very high.
It may end up being a false economy to postpone solving the problem.

Regards,

Mark

-- 
 Mark Birbeck, formsPlayer

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

 standards. innovation.