OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 23 - proposed resolution (add rationale) for TC


Hello,

Yaron, i am more than happy to do it like you proposed, i was just not sure if issues can be closed without vote, or if memebers can give action points to the editors without a tc resolution.

So if nobody inssits on a more formal decision, I will ask on the TC for consensus to ask editors for a rationale. 

And i will shortly discuss the general "language" the spec should be in. right now it is pretty informal, so it wont hurt to reference sample material.

Greetings
Bernd


-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, August 19, 2003 8:48 PM
To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 23 - proposed resolution (add rationale)
for TC


In your letter you propose three voting topics:

a) are we willing to keep the sequence activity, even if it can be replaced by flow with additional links
b) do we want to add a rationale, to clearify this redundancy in the spec
c) are we willing to enhance the spec with references to samples or whitepapers?

I think we should only have votes when there is a real dispute that needs resolution. Perhaps I'm reading the group wrong but I haven't heard any significant portion of the group indicate that it would want to remove sequence so why would we need to vote on the issue? Therefore I suggest that we do not vote on the 'a' issue.

The 'b' issue is purely editorial and therefore falls within the general remit of the editors. You can simply ask them to make the change and they can say yes or no. If they say no then it would be appropriate to have a vote. But so far the sense I get is that the editors won't have a problem making this clarification.

As you say yourself the 'c' issue isn't really something that can be voted on, after all, it's motherhood and apple pie, but it would make a fine topic for discussion on a conference call.

My suggestion is that you propose your language to the editor's and see what they say. If they say yes (as I expect) then once they make the change the group can vote to close this issue as 'resolved'. If they refuse the change then it would be appropriate to move that 'b' be put up for a vote.

		Make Sense?

			Yaron

> -----Original Message-----
> From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
> Sent: Monday, August 18, 2003 10:30 AM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 23 - proposed resolution (add rationale) for
> TC
> 
> 
> Hello,
> 
> here is my proposed resolution to the Issue 23, for 
> discussion on the upcoming TC, as announced by Duane:
> 
> Short Description:
> 
>   There are some semantic requirements in the BPEL1.1 spec, 
> which can be modeled with implicite links. 
>   I have raised the following two "issues" in my original 
> mail, and will suggest a combined solution:
> 
>    a) a sequence can be expressed as a flow, with additional 
> links (not trivially)
> 
>    b) instead of searching for ready activities with no 
> destination links (in a flow) the 
> 	runtime engine can optimize this search by linking from 
> the flow activity to all 
> 	its included ready activities while parsing the process 
> definition
> 
> 
> First the easy part: I admit that part of the issue (b) is 
> out of scope for the specification, since it is
> only a possible runtime optimization, which may not apply to 
> all implementation architectures. Therefore
> I decide to resolve this part of the issue as "no need to do 
> anything".
> 
> Part (b) of the issue however was discussed in some threads 
> on the mailing list, and I feel we have some consence on this 
> issue. Initially it was mentioned by me, because it was 
> confusing (for me) to analyse the speciication and find two 
> constructs (sequence vs. flow), which can basically express 
> the same sematic. In fact, sequence is just a short notation 
> for flows. Looking at our sample Implementation, I can see 
> that this requires (some) additional code to support both 
> constructs. Therefore I questioned this redundancy in the Spec.
> 
> There has been discussion to 
> 
> 1) remove sequence (or even all?) constructs, which are short notation
> 	- to make the spec less ambiquos, therefore remove the 
> risk of interoperability issues
> 	- and to allow faster implementation of the spec
> 
> 2) keep the seuqence notation, as it might
>    - allow modelling tools to better express the intend of 
> the modeller
>    - allow analysis tools to easier parse the overall 
> structure of the process
>    - allow backward compatibility (no unneeded change)
>    - allow expression of sequences, which are otherwise not 
> at all trivial.
> 
> (For the last point I remind everybody of the great mail from 
> Ram Jeyaraman which was in detail explaining, what you have 
> to do to replace a sequence with a flow, preserving link sematics).
> 
> I feel, that we agree, that the additional costs for the 
> seuqnece implementation is far outweighted by the beneftis of 
> solution (2). But since my concern about "beeing confused by 
> this redundacy" is still valid, I propose the following trade-off:
> 
> Add a comment, rationale or normal text (whatever is 
> preferred by the editing team) to explain it:
> 
> 
> -- old --
> 12.1 Sequence (p.58)
> 
> A sequence
> ...
>   </sequence>
> -- /old --
> -- add --
> Rationale: the structured activity 'sequence' is a natural 
> way of expressing sequential processing. It is therefore 
> present in the Specification, even when it is possible to 
> achieve the exactly same semantic with an structured flow, 
> which has some additional links to preserve sequential 
> processing semantics. It is important to emphasize, that 
> transforming an sequence, with additional conditional links 
> into a flow is not trivial, thats one of the reasons for 
> having both constructs in BPEL. [For Information purpose 
> only, you can check out the sample transformation on http://].
> -- /add --
> 
> 
> There are 3 Key points to decide on:
> 
> a) are we willing to keep the sequence activity, even if it 
> can be replaced by flow with additional links
> b) do we want to add a rationale, to clearify this redundancy 
> in the spec
> c) are we willing to enhance the spec with references to 
> samples or whitepapers?
> 
> 
> Personally I think we can directly vote on point a) and b) 
> and should briefly discuss point c) as it is a general 
> discussion, if we want to make the spec formal or "helpful". 
> Perhaps point c) is something for an additional implementators guide?
> 
> Greetings
> Bernd
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]