- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Mon, 17 May 2010 19:11:20 -0700
- To: Forms WG <public-forms@w3.org>, www-forms@w3.org
Alain & all, > I tested your teaser (I changed bind/@ref to bind/@nodeset): > > EMC Formula: "banana" > Mozilla extension: "Joe" > XSLTForms: nothing Orbeon Forms returns "banana". > According to XForms 1.1 recommendation, > > if the binding element expresses a model attribute that refers to a model > other than the one containing the context node, then the context node of the > in-scope evaluation context is changed to be the top-level document element > node of the default instance of the referenced model, and the context > position and size are changed to 1. I think this is the key! Good to point this out. > [the output Element] cannot bind to element nodes that have element > children. > If element child nodes are present, then an xforms-binding-exception occurs. > > So, my point of view is that an exception should occur and I'm still proud > of XSLTForms for not being completely wrong ;-) > > It might be easier for developer if context could consist of a node for each > model... then "Joe" would be displayed, don't you think? You are right. Although it was not intended in my example that xforms:output would point to an element containing nested elements! Here is a version that should produce "Joe": http://gist.github.com/404511 > BTW, is there a price to win? ;-) Unfortunately no price except for the pride of pointing to the right answer ;) -Erik > > -Alain > > All, > > Here is a little puzzle: > > http://gist.github.com/401939 > > What should the output sow, "Joe", or "banana"? > > First, is it clear that it is allowed to refer by id to a bind that > does not belong to the current model? > > If so, since by specifying @model="model1" we are not actually > changing the model in the sense that there is no ancestor @model > attribute changing the model, should @model="model1" ensure that the > nested xforms:output point to a node in model1 rather than model2? > > -Erik > > > >
Received on Tuesday, 18 May 2010 02:42:46 UTC