- From: John Boyer <boyerj@ca.ibm.com>
- Date: Mon, 13 Aug 2007 22:11:31 -0700
- To: "Mark Birbeck" <mark.birbeck@formsPlayer.com>
- Cc: "Aaron Reed" <aaronr@us.ibm.com>, www-forms@w3.org
- Message-ID: <OF811899BB.E2FBB085-ON88257337.001904FC-88257337.001C8581@ca.ibm.com>
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 Tuesday, 14 August 2007 05:11:42 UTC