RE: evaluation context

I came across this same issue a while ago (see "Evaluation Context of <bind>
Computed Expression" around 9/12). For the time being, I have implemented
contexts as follows:

* Each XForm Instance Document has a context node stack.

Each enclosing element pushes it's selected node[set] (ref/nodeset) onto a
NodeStack maintain by an Instance (or XForm) object. When the enclosing
element ends, the context node[set] is popped off the stack.

This means there is one context node for each <xform/> defined in the
document, and not one global context node.

I would also like to suggest that an "XForm Context" be introduced into the
spec. This would state the following:

The context xform for non-outermost binding elements is determined by the
xform attribute of the immediately enclosing element. If no xform attribute
is present on an enclosing element, the default (first in document order)
xform is used.


I also agree that the current scheme of selecting the xform outside of the
binding expression creates limitations. For instance, the computed
expressions on the <bind/> element can only apply to the specified xform.

<bind id='b1' xform='x1' ref='bla/bla/bla' calculate='...'
relevant='bla/bling/blam = 5'/>

This makes it impossible to use the computed expressions that refernce data
in other xforms.. For instance, what if I need to calculate a field in a PO
XForm based on data stored in a Catalog XForm. 

Extending the computed expressions to something like the following would be
very powerful.

<bind id='b1' ref='bla/bla/bla' xform='f1'>
	<relevant xform='f2' expr='/should/i/show/it = 1'/>
	<calculate xform='f3' expr='/catalog/items/item[1]'/>
</bind>


We could take this discussion much further. 

- Ryan


-----Original Message-----
From: Josef Dietl [mailto:josef@mozquito.com]
Sent: Thursday, October 18, 2001 10:15 AM
To: Jérôme Nègre; www-forms@w3.org
Subject: RE: evaluation context


Hi Jérôme,

this is really a very interesting approach that you bring up there. As
far as I can tell, there is no definitive answer at this time. 6.3
defines that "The context node for non-outermost binding elements is
determined by evaluating the binding expression of the immediately
enclosing element." This breaks down in your example because you (try
to) reset the context node by adding a "xform" attribute to the inner
element. This makes sense but contradicts the earlier statement about
the context node - with other words, you have discovered a gap in the
spec.

We ourselves have discovered that we need a way to merge the "xform"
attribute with the "ref" and "nodeset" attributes, but we simply haven't
figured out how to do that yet. Once we manage to do that, I hope that
your problem will solve itself - until then, I appreciate your patience
(and of course your report to begin with).

We'll keep you up to date.

Josef

> -----Original Message-----
> From: Jérôme Nègre [mailto:jerome.negre@ecl2000.ec-lyon.fr]
> Sent: Tuesday, October 16, 2001 4:29 PM
> To: www-forms@w3.org
> Subject: evaluation context
> 
> 
> Hi,
> 
> what is the context-node of a non-outermost element *with an xform
> attribute* ?
> 
> Is it determined by evaluating the immediatly enclosing 
> element as stated in
> chapter 6.3, or is it the <xform:instance> element indicated 
> by the xform
> attribute ?
> 
> I think the latter would be more useful, like in the 
> following example :
> 
> <xform:xform id="form_1">
> ...<!-- definition of possible answers -->
> </xform:xform>
> <xform:xform id="form_2">
> ... <!-- choice of user -->
> </xform:xform>
> 
> ...
> 
> <xform:selectOne xform="form_2" ref="path/to/choice">
> ...
> <xform:repeat xform="form_1" nodeset="list/of/possible/answers">
> <xform:itemref ref="@value"><xform:caption><xform:output ref="@name"
> /></xform:caption></xform:itemref>
> </xform:repeat>
> </xform:selectOne>
> 
> So, is it possible to have something like that, or is there 
> another way to
> do this ?
> 
> Thanks for your feedback,
> 
> Jérôme Nègre
> 
>

Received on Thursday, 18 October 2001 11:01:29 UTC