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
