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

["Satish Thatte" <satisht@microsoft.com>]

Separately, Yaron, completely rewriting the existing text of 8.1 without  running it by the rest of us was a bad idea.  We are not in the phase of rewriting the spec.  I would like us to have a discipline of making only the really necessary changes and additions in this phase so that we don't have to go back and check every new usage every editor introduces.  For instance we have never used the word "programmer" in the spec before and I am very uncomfortable with its use given the tendency to equate WS-BPEL to a programming language.  This is not the sort of innovation we should make without consultation.
 
Satish

________________________________

From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wed 11/24/2004 4:59 PM
To: Alex Yiu
Cc: ygoland@bea.com; bpel spec
Subject: Re: [wsbpel-spec-edit] Summary of my commit



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