- From: John Boyer <boyerj@ca.ibm.com>
- Date: Fri, 10 Aug 2007 13:43:43 -0700
- To: Aaron Reed <aaronr@us.ibm.com>
- Cc: www-forms@w3.org, www-forms-request@w3.org, www-forms-editor@w3.org
- Message-ID: <OFCB912A81.19FF6556-ON88257333.006F0473-88257333.0071DE5F@ca.ibm.com>
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
Received on Friday, 10 August 2007 20:44:08 UTC