W3C home > Mailing lists > Public > www-forms@w3.org > August 2007

Re: context for origin on xf:insert

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 

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 

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 

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?

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

"Aaron Reed" <aaronr@us.ibm.com>
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.



  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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:20 UTC