Re: ACTION-1959 - Propose how to fix the implicit model identification with context nodes

All,

I have modified the text to change the resolution of the model in all
the case discussed in this thread. This removes references to the
"context node":

http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XForms_2.0&diff=3903&oldid=3895

For simplicity, I have settled on only using the `model` attribute,
but not the `bind` attribute. I think that is the best thing to do,
and this change is particularly harmless since we are talking about a
corner case here.

This said, in general the logic for nested model switching remains
unsatisfactory. Issues around this were raised in the past and not
fully resolved. For example I found this related and unresolved action
item:

"ACTION-619 - Bruchez to ask public-forms and www-forms implementors -
When you switch models, to what context do you switch?  root element
or do you go back to the in-scope context?  Please cite use cases that
support your decision."

I think that nested model switching should always use the `model`
attribute only to determine a "current' model, and then go back to the
in scope context. But we don't necessarily have to solve this right
now.

-Erik


On Tue, Dec 3, 2013 at 10:39 PM, Erik Bruchez <erik@bruchez.org> wrote:
> All,
>
> During our last call, Nick noticed that there were quite a few
> remaining occurrences of the term "context node" in the spec.
>
> In particular, there are 12 references to the model "associated with
> the in-scope evaluation context node", in the following sections:
>
> - 3.3.2 Linking Attributes
> - 10.5.9 The xforms-link-exception Event
> - 11.9 The rebuild Element
> - 11.10 The recalculate Element
> - 11.10 The recalculate Element
> - 11.12 The refresh Element
> - 11.13 The reset Element
>
> In all those cases, the idea is that we need to dispatch an event to a
> particular model, or to perform an action on a model, without
> explicitly specifying it.
>
> The spec so far has taken the approach that the determination is
> performed by looking at the "context node". The context node is
> dynamically determined via XPath expressions.
>
> With XForms 2 and XPath 2 or greater, this can be a problem, as there
> might not be a context *node*, but a context *item*. For example:
>
>     <repeat ref="1 to 10">
>       <rebuild event="..."/>
>       ...
>     </repeat>
>
> In this example, the current XForms 1.1 algorithm doesn't work as
> there is no context node.
>
> Since we have a `model` attribute which already determines statically
> a context model, I suggest using that as a way to determine a model
> when one is needed.
>
> So with the example above, the `rebuild` action would rebuild the
> default model. But if you write:
>
>     <group model="model2">
>         <repeat ref="1 to 10">
>           <rebuild event="..."/>
>           ...
>         </repeat>
>     </group>
>
> then the `rebuild` action would rebuild model `model2`.
>
> Here is an exampe showing that, with XPath 2, you can easily change
> the context model dynamically:
>
>     <group model="model1">
>         <!-- $v1 points to a node in `model1` -->
>         <var name="v1" value="."/>
>         <group model="model2">
>             <!-- $v1 points to a node in `model2` -->
>             <var name="v2" value="."/>
>
>             <group context="if (condition) then $v1 else $v2">
>                 <!-- Here the XPath context might point to a node in
> `model1`, `model2` (or maybe no node at all) -->
>                 <rebuild event="..."/>
>             </group>
>
>         </group>
>     </group>
>
> Using the static `model` attribute instead adds predictability.
>
> In addition to the `model` attribute, we could use the `bind`
> attribute, which also statically determines a model:
>
>     <group bind="my-bind-in-model2">
>         <repeat ref="1 to 10">
>           <rebuild event="..."/>
>           ...
>         </repeat>
>     </group>
>
> In short:
>
> 1. I am advising we determine a model statically instead of dynamically.
> 2. To do so, we must use the `model` attribute, and maybe consider in
> adition the `bind` attribute as well.
>
> This does the following:
>
> 1. Makes resolution simpler and more predictable.
> 2. Doesn't require that a context *node* be present and so is
> compatible with XForms 2.
>
> (You could make a case that dynamically determining the model is a
> feature, but I believe that if we want it we should make it possible
> via an attribute on the actions.)
>
> Feedback welcome.
>
> -Erik

Received on Wednesday, 11 December 2013 07:28:52 UTC