[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-spec-edit] Summary of my commit
I'm find with removing the word atomic but I think there were enough people who were attached to the word that before removing it we should seek the opinion of the larger group. Yaron Assaf Arkin wrote: > In my reading the text "that assignment activities are atomic" is > explained by the rest of the paragraph and not referenced anywhere else. > Which means it's redundant -- the definition will be complete without > it. If it's just redundant, I'd say keep it. If it keeps up coming as a > source of confusion since people read the spec and use a definition of > 'atomic' not conveyed in the spec, then it can be argued that the > definition is incomplete with that text. > > I'm proposing that if this is an issue to the reader, we consider an > editorial change to improve the language, not a change to the behavior > we voted for. > > Assaf > > Alex Yiu wrote: > >> >> Hi, >> >> The "atomic" term in the original spec text has its own meaning already: >> "An important characteristic of assignment in BPEL4WS is that >> assignment activities are atomic. If there is any fault during the >> execution of an assignment activity, the destination variables are >> left unchanged as they were at the start of the activity. This applies >> regardless of the number of assignment elements within the overall >> assignment activity." >> >> I read the text as: when there are multiple <copy> within one >> <assign>, the result of multiple <copy> is atomic. >> >> I would suggest the new text to look like: >> "An important characteristic of assignment in BPEL4WS is that >> assignment activities are atomic. If there is any fault during the >> execution of an assignment activity, the destination variables are >> left unchanged as they were at the start of the activity. This applies >> regardless of the number of _<copy>_ elements within the overall >> assignment activity. _*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. _" >> >> If one wants to remove atomicity completely, then I believe it >> requires filing of another BPEL issue. >> >> Does it make sense? >> >> Thanks! >> >> >> Regards, >> Alex Yiu >> >> >> Assaf Arkin wrote: >> >>> 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 >>>> >>>> >>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]