- From: John Boyer <boyerj@ca.ibm.com>
- Date: Wed, 15 Aug 2007 17:07:08 -0700
- To: David Landwehr <david.landwehr@picoforms.com>
- Cc: "Aaron Reed" <aaronr@us.ibm.com>, "Mark Birbeck" <mark.birbeck@formsPlayer.com>, www-forms@w3.org, www-forms-request@w3.org, Forms WG (new) <public-forms@w3.org>
- Message-ID: <OF7AA57CD4.C1B9A334-ON88257338.00826743-88257339.0000A79D@ca.ibm.com>
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.
Received on Thursday, 16 August 2007 00:07:51 UTC