W3C home > Mailing lists > Public > public-xformsusers@w3.org > December 2016

Re: Processing nested binds

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Wed, 07 Dec 2016 11:09:08 +0100
To: "Erik Bruchez" <ebruchez@orbeon.com>
Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>, "Nick Van den Bleeken" <Nick.Van.den.Bleeken@inventivegroup.com>
Message-ID: <op.yr3ihi0hsmjzpq@steven-aspire-s7>
This is a great relief to me, because I feared that there was some  
essential point I was missing.

>>>>> 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.
>
> Re-reading, it does express that!
>
> (By the way my understanding of what we appeared to disagree on during  
> the last call was a bit different: I thought the issue was about how an  
> >XPath expression in the nested bind evaluated given its context. But  
> maybe I misunderstood that.)
>
> To clarify: your point is that if section 6.2 expresses both what  
> happens:
>
> 1. with single-item bindings
> 2. and with sequence bindings
>
> then text which is specific to `<bind>`:
>
> 1. does not need to be present
> 2. or worse, must not be present or there is room to interpret the text  
> as requiring more repetitions of nested `<bind>` elements than is  
> desired.
>
> Is this a correct understanding?
Exactly.

>
> As far as I am concerned, as long as we agree on the actual effect that  
> nesting binds has, then we are good.
Brilliant! I shall modify the text accordingly.

Steven
Received on Wednesday, 7 December 2016 10:09:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:47 UTC