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

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

Thanks!

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Monday, November 29, 2004 5:25 PM
To: Satish Thatte
Cc: Assaf Arkin; Alex Yiu; bpel spec
Subject: Re: [wsbpel-spec-edit] Summary of my commit

I agree and have removed the changes.

To make matters even more interesting it turns out that I had another 
screw up besides putting in the 8.x changes. When I read issue 137 in 
the issue list I read the resolution  "proposed and agreed at f-t-f, 22 
Sept 2004" as meaning that there had never been a written resolution to 
the issue. So I checked the meeting minutes and just made up text that 
seemed consistent with my understanding of what was agreed to.

But my assumption that there was no actual resolution was just plain 
wrong. There was a written proposal 
<http://lists.oasis-open.org/archives/wsbpel/200409/msg00144.html> and I

have an obligation to implement it.

Therefore I have done two things:

#1 - I have removed all of my changes related to issue 137, specifically

the alterations to section 8.x. I will send out a separate proposal to 
the editors list for changes I would like to make that we can then
discuss.

#2 - I have edited in the text passed in the issue 137 resolution.

I am now done with the pen and passing it to Alex.

	Yaron


Satish Thatte wrote:
> 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
>  >
>  >
> 
> 
>