Re: [wsbpel-spec-edit] Summary of my commit

[Assaf Arkin <arkin@intalio.com>]

I would prefer if we not use the term atomic at all, just describe the 
expected behavior. It provides enough precision without any confusion.

Assaf

Alex Yiu wrote:

>
> Hi, Yaron and others,
>
> For Issue 166,
> Yaron's change of text:
> "The assign activity is treated as if it were atomic. *This means 
> that* the assign activity MUST be executed as if, for the duration of 
> its execution, it was the only activity in the process being executed. 
> The mechanisms used to implement the previous requirement are 
> implementation dependent. "
>
> This text essentially implies: the "atomic" term in the text is NOT 
> the "atomic" term in ACID.
> The "atomic" term is more similar to "atomic" operation from typical 
> CPU machine instructions or traditional / transaction-unaware 
> programming language viewpoint.
>
> If we change the text to become:
> "The assign activity is treated as if it were atomic. *Also,* the 
> assign activity MUST be executed as if, for the duration of its 
> execution, it was the only activity in the process being executed. The 
> mechanisms used to implement the previous requirement are 
> implementation dependent. "
>
> Then the implication is gone.
> What do you guys think?
>
> I know it's a kind of terminology nitpicking issue.
> I just want to make sure the edit group make a conscious decision here.
>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
> Yaron Y. Goland wrote:
>
>> For issue 137 I completely rewrote section 8.1 to make it a lot more 
>> concrete and illustrative (the existing text never even used the word 
>> property) and then deleted a few sentences from 8.2 and added in some 
>> normative language around refreshing property values and assigning to 
>> non-Lvalues.
>>
>> For issue 166 the language I put into 14.3 is:
>>
>> The assign activity is treated as if it were atomic. This means that 
>> the assign activity MUST be executed as if, for the duration of its 
>> execution, it was the only activity in the process being executed. 
>> The mechanisms used to implement the previous requirement are 
>> implementation dependent.
>>
>> For 175 it wasn't immediately clear to me which section was best but 
>> 3 seemed the least awful. Here is the language I inserted:
>>
>> While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 
>> as possible there are two areas where such compatibility has proven 
>> impossible. One area, discussed later in this document, is in fault 
>> naming. The other area is in support for overloaded operation names 
>> in WSDL portTypes. A BPEL processor MUST reject any WSDL portType 
>> definition that includes overloaded operation names. This restriction 
>> was deemed appropriate as overloaded operations are rare, they are 
>> actually banned in the WS-I Basic Profile and supporting them was 
>> felt to introduce more complexity than benefit.
>>
>> For 178 I inserted the following language into section 13:
>>
>> All handlers on a scope are lexically subordinate to the scope and so 
>> can access all variables, partnerLinks and correlation sets defined 
>> on the scope and its linear ancestors subject to any restrictions 
>> unique to the handler type specified elsewhere in this document.
>>
>>     Thanks,
>>
>>         Yaron
>
>

S/MIME Cryptographic Signature