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
>
>
