Re: context for origin on xf:insert

Actually, Aaron, I think that the bulk of the confusion is coming from the 
fact that the context attribute should not be ignored if there is a bind 
attribute.

Frankly, we are still experimenting with the context attribute, but the 
hope is that in XForms 1.2 we can make it generally available everywhere. 
But it really seems that we need to hit the nail squarely on the head in 
the 1.1 timeframe so that we will have a properly generalizeable 
attribute.

Frankly, we should have made context into a generalized attribute in 1.1, 
and I still don't see why we don't just chuck it into the common 
attributes bundle.  It certainly would have made this flaw obvious sooner. 
 And in fact, even though I lost the argument last time around, we may 
still want to make it so because I really think that we need to fix the 
flaw and when we do we will see that a fully generalizable context 
attribute must also affect how @if and @while are evaluated.  At that 
point, the only reasonable place to define @context will be in the common 
attributes because @context should be part of how the in-scope evaluation 
context is determined.

Anyway, the Orbeon and Sidewinder guys are correct that the eval context 
of origin should be the in-scope eval context *because* a number of 
working group members did not want it to be based on the nodeset binding, 
which was originally the case over a year ago. 

For the record, there are other attributes which do not use the single 
node binding or nodeset binding (with first node rule) for the context 
node.  Among them are if, while, at, and context (OK including the last 
one could be seen as being a bit cheeky, but it really *has* to be 
evaluated before the SNB or NSB so it's actually a great example). 

Moreover, making the other attributes of an element evaluate relative to 
the SNB or NSB has turned out to be not such a good idea.  I think it 
occurred because we did not have a well-developed notion of in-scope 
evaluation context at the time, and we actually have David Landwehr to 
thank for formalizing the concept for us.  Using the binding for context 
immediately shows itself to be a problem because anywhere that a nodeset 
binding is used, the first node rule must be applied.  It would have been 
far better if XPath had defined the input context as being an entire 
nodeset plus a position and size, not just a single node.

In conclusion, the bug here is that @context should reset the in-scope 
evaluation context whether or not the @bind attribute is used to express 
the nodeset binding.  So, I'll take that forward to the group now and, who 
knows, they may even let me fix it by moving @context to the common 
attributes where it belongs!  Somebody, please please please say you 
support this.  Nobody, please please please say you object.

(:-)
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





Aaron Reed <aaronr@us.ibm.com> 
Sent by: www-forms-request@w3.org
08/09/2007 04:41 PM

To
www-forms@w3.org
cc

Subject
context for origin on xf:insert







Hi,

In XForms 1.1, I have a question about @bind.  The contents of this 
question are inspired by a testcase on a bug opened against our Mozilla 
XForms extension (https://bugzilla.mozilla.org/show_bug.cgi?id=391586).

If I have:

   <xf:group ref="instance('containers')/source/date">
     <xf:trigger>
       <xf:label>copy source date (containing text)</xf:label>
       <xf:action ev:event="DOMActivate">
         <xf:insert bind="date" origin="." position="after" at="1"/>
       </xf:action>
     </xf:trigger>
   </xf:group>

should the context node for the evaluation of @origin's XPath expression 
be the result of the evaluation of @bind?  Or should the context node 
for @origin be instance('containers')/source/date?

The spec says -> "The insert context is determined. If the bind 
attribute is present or if the context attribute is not given, the 
insert context is the in-scope evaluation context. Otherwise, the XPath 
expression provided by the context attribute is evaluated using the 
in-scope evaluation context, and the first node rule is applied to 
obtain the insert context." I would think that the result of @bind's 
evaluation would be the context node since that is how xpath evaluations 
are evaluated on almost every other xforms element in the spec (for 
example setvalue) and this would also logically explain why @context is 
ignored if @bind is present.  But both the Orbeon and Sidewinder 
implementations seem to think that the context should be 
instance('containers')/source/date.

I assume one of us is right :)  And I am guessing that it is probably 
Orbeon and Sidewinder since the spec mentions in-scope evaluation 
context instead of 'Nodeset binding'.  However, it is quite confusing to 
have 'Node Set Binding' attributes mentioned in the insert action, have 
@context ignored if @bind is present, but then not have @bind provide 
context for the xpath evaluations even though it provides context 
elsewhere in the spec.  It might be worth a special mention in the spec.

Thanks for your help,
--Aaron