Re: context for origin on xf:insert

Hi David,


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'.

--Aaron

David Landwehr wrote:
> 
> It is always a head spinner dealing with the insert action and all these 
> conditions depending on if an attribute is present or not.
> 
> My feeling is that a declarative language should be so simple that the 
> author should immediately be aware what a specific action is doing 
> without going into a big analysis. I think that the insert action does 
> not provide the clarity and simplicity it ought to and that this can 
> also be proven that implementors keep coming up with questions and 
> problems regarding the action.
> 
> This problem could be solved by spitting the functionality of insert 
> (and maybe delete) up in separate actions which will provide simplicity 
> and clarity.
> 
> Best regards,
> David
> 
> 
> 
> On Aug 10, 2007, at 1:41 AM, Aaron Reed wrote:
> 
>>
>> 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 Sunday, 12 August 2007 17:31:23 UTC