Re: Processing nested binds

On Tue, 06 Dec 2016 18:29:12 +0100, Erik Bruchez <ebruchez@orbeon.com>  
wrote:

> 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="...">
>      ...
Well, of course, I understand that. And apparently so does 6.2 In-scope  
Evaluation Context, because it treats them differently, since a group  
doesn't "express a sequence binding", and a bind does.

> In the case of `<bind>`, we want to achieve unrolling of the nested  
> binds. If >that helps, think that `<bind>` basically works like  
> `<repeat>`.
Which is what is happening in the above, surely?
"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"/>"

> 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 line doesn't apply to group, because that's from the rule for  
Sequence Bindings.

The line that applies to group is just above it:
"If the ancestor expresses a Single Item Binding, then the context item is  
the one resulting from the binding, and the size and position are 1."

> That's the general rule about bindings. If `<bind>` was indeed working  
> like >`<group>`, that text would be enough.
It's the next bit of the section you quoted that matters:
"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."

> 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,
But that's exactly what *is* happening isn't it?

> 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.
Which is what 6.2 says for Sequence Bindings.

> 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.
My point being, that that distinction is exactly what 6.2 seems to make,  
and I don't understand why you think it doesn't.

Steven