Re: Processing nested binds

On Tue, Dec 6, 2016 at 1:38 AM, Steven Pemberton <steven.pemberton@cwi.nl>
wrote:

> At the recent call, you persuaded me I was wrong on this, so now I want to
> understand why I was wrong, so that I can fix the spec to make it clearer,
> so that others don't make the mistake I made.
>
> So using the spec, I'll explain the steps I thought happened with <bind>,
> and I would be grateful if those of you who said I was wrong to point out
> the error of my thinking.
>
> As an example I will use the following instance, and I am particularly
> interested in the nested <bind ref="b"/>
>
> <model>
>     <instance>
>         <data xmlns="">
>             <a><b/></a>
>             <a><b/></a>
>             <a><b/></a>
>         </data>
>     </instance>
>
>     <bind ref="a" readonly="true()">
>         <bind ref="b" type="integer"/>
>     </bind>
> <model>
>
>
> Rebuild says:
> "Each bind in the model is applied." [Note that this would include the
> nested bind]
>
> The bind Element says:
> "See Evaluation Context for details on how the evaluation context is
> determined for each attribute of the bind element."
>
> Evaluation Context says:
> "a binding element is any element that can have a binding attribute, while
> a bound element is a binding element that explicitly has a binding
> attribute."
>
> "[If the binding of an element is expressed with the bind attribute, then
> the resulting item or sequence is obtained from the referenced bind
> element; otherwise] the in-scope evaluation context provides the default
> evaluation context for a binding."
>
> "For binding elements that have no ancestor binding elements, the initial
> context size and position are 1, and the context item is the top-level
> document element node of the default instance of the model referenced by
> the model attribute, if any, otherwise of the containing model, if any,
> and otherwise of the default model."
>
> "For other binding elements, the nearest ancestor binding element is used:
> ...
> If the ancestor expresses a Sequence Binding, then the context item is the
> sequence's first item, the position is 1, and the size is the size of the
> sequence. Additionally, an occurrence of the original binding element is
> generated for each of the items in the sequence, with a dynamic in-scope
> evaluation context that has a context item of the item of the sequence for
> which the occurrence was generated, a size of the size of the sequence,
> and a position of the position of the generated item in the sequence."
>
> So expressing a context as <<elem, size, position>>:
>
> The outermost bind has no ancestor; so its context is <<data, 1, 1>>
> The innermost bind has an ancestor that expresses a sequence binding. So
> the context is <<a[1], 3, 1>>.
> Furthermore, the innermost bind is regenerated for each element of
> the sequence:
>     <<a[1], 3, 1>> <bind ref="b" type="integer"/>
>     <<a[2], 3, 2>> <bind ref="b" type="integer"/>
>     <<a[3], 3, 3>> <bind ref="b" type="integer"/>
>
> So from my reading of the spec, without having to use the bit of spec that
> says
> "For each item in the sequence, any child bind elements are recursively
> processed as described in the three points of this list.", the nested bind
> is already processed correctly


There is a difference between:

<bind ref="...">
   <bind ref="...">
      ...

and:

<group ref="...">
   <group ref="...">
      ...

In the case of `<bind>`, we want to achieve unrolling of the nested binds.
If that helps, think that `<bind>` basically works like `<repeat>`.

With `<group>`, we do not want to achieve that. `<group>` doesn't unroll
and instead uses the "first item rule". So that is why the text in "6.2
In-scope Evaluation Context" says that:

    "the context item is the sequence's first item,"

That's the general rule about bindings. If `<bind>` was indeed working like
`<group>`, that text would be enough.

But that text is *wrong* when we are talking about unrolling nested
`<bind>`: in that case, the context item must become, successively, each
item of the enclosing bind's sequence: 1, 2, up to n, in the same way that
when a `<repeat>` unrolls, we say that things work as if we had implicit
nested `<group>` bound to each item in the repeat sequence.

So the `<bind>` text is specific for the a reason similar to `<repeat>`.
And I think you have to make that distinction between the two cases:
general handling of bindings for things like `<group>`, `<switch>`, etc.,
and handling of repeated constructs like `<repeat>` and `<bind>`. There
doesn't seem to be a way around making a distinction because the result
that needs to be achieved is different.

-Erik