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.
>
>