[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 99 - Some proposed wording
Yaron, We agreed that any basic activity (except <terminate> and <reply>) may appear at the beginning of BPEL abstract processes. The purpose of value "abstract process fragment" is to "prevent misunderstanding" such as "did the author of a particular abstract process really mean to put at the beginning of the abstract process activity different from <receive>". In this sense the value is redundant. It is up to designer of a particular abstract process to check whether the process definition is correct or not. Or? Regarding process taxonomy: The language specifies two types of processes with different use cases, and clear semantic and syntactic differences. Abstract process fragments do not represent a new type of abstract processes. There is only one flavor of abstract processes. In this sense the proposal does not fit in with already defined process taxonomy. Regards, Ivana > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Montag, 17. Mai 2004 20:30 > To: Trickovic, Ivana > Cc: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue - 99 - Some proposed wording > > > Please see below > > Trickovic, Ivana wrote: > > > > > > > Yaron, > > > > I have a few more comments/questions. > > > > The proposal introduces a new value for attribute > abstractProcess which > > is not consistent with the current semantics of that > attribute. We have > > in BPEL a clear "process taxonomy" and "abstract process > fragment" does > > not really fit in with it. > > > In what way does an abstract process fragment fail to fit in > with BPEL's > process taxonomy? > > > In addition, value "abstract process fragment" seems > redundant (or at > > least the language will be overloaded). The purpose of that > value is to > > be able to double-check an abstract process definition. > > > For the identification of an abstract process as a fragment to be > redundant the information must have previously been made available > elsewhere in the BPEL processing model. Could you please > identify where > that was? > > > Would you clarify the relationship between this proposal and your > > proposal for issue 107? > > > I intended my proposal to remove some ambiguities in the > semantics of a > BPEL process that the original proposal introduced. > > > Regards, > > > > Ivana > > > > Thanks, > Yaron > > > > -----Original Message----- > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > Sent: Montag, 10. Mai 2004 22:39 > > > To: Trickovic, Ivana > > > Cc: wsbpel@lists.oasis-open.org > > > Subject: Re: [wsbpel] Issue - 99 - Some proposed wording > > > > > > > > > The only syntactic difference is that an abstract process > > > MUST contain > > > one or more start activities and an abstract process fragment > > > MUST NOT > > > contain any start activities. > > > > > > The purpose of creating the distinction is to prevent > > > misunderstandings. > > > If one is given an abstract process definition without a > > > start activity > > > and if the abstract process fragment identifier isn't > > > available then one > > > must always wonder 'is this abstract process schema invalid > > > or did they > > > mean to leave out a start activity'? By introducing an > > > explicit switch > > > we remove the ambiguity. > > > > > > Yaron > > > > > > Trickovic, Ivana wrote: > > > > > > > > > > > > > > > Yaron, > > > > > > > > Would you please explain the difference between abstract > > > processes and > > > > abstract process fragments (except syntactical > difference: abstract > > > > processes must contain at least one "starting activity")? > > > What would be > > > > the semantics of abstract process fragments? What are > use cases? > > > > > > > > Thanks, > > > > > > > > Ivana > > > > > > > > > -----Original Message----- > > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > > Sent: Donnerstag, 6. Mai 2004 01:46 > > > > > To: wsbpeltc > > > > > Subject: [wsbpel] Issue - 99 - Some proposed wording > > > > > > > > > > > > > > > I am thinking of putting the following up for vote as a > > > resolution to > > > > > issue 99. What do y'all think? > > > > > > > > > > Yaron > > > > > > > > > > The introductory sentence in section 15 shall be amended to > > > > > read "These > > > > > are extensions for the business protocol usage pattern." > > > > > > > > > > The following text or a variant adopted at the > discretion of the > > > > > editor's group which only differs in non-normative ways > > > where changes > > > > > are made for editorial purposes shall be inserted into > > > section 15: > > > > > > > > > > ------------------------------ > > > > > > > > > > 15.X Abstract Process Fragments > > > > > > > > > > An abstract process that chooses not to specify how it is > > > > > initiated is > > > > > referred to as an abstract process fragment. An > abstract process > > > > > fragment follows all the same syntactic and semantic > > > rules as other > > > > > abstract processes with the exception that they do not > > > > > specify how they > > > > > are initiated and therefore do not contain start activities. > > > > > An abstract > > > > > process fragment MUST set the value of the abstractProcess > > > > > attribute on > > > > > the process element to 'abstactFragment'. If an abstract > > > process does > > > > > not contain start activities and the abstractProcess > > > > > attribute value is > > > > > not set to 'abstractFragment' then the abstract process > > > definition is > > > > > invalid. > > > > > > > > > > ------------------------------ > > > > > > > > > > The first reference to the abstractProcess attribute in > > > section 6.2 > > > > > shall be amended to include the option > > > 'abstractFragment'. The second > > > > > reference shall be amended to read 'This attribute specifies > > > > > whether the > > > > > process being defined is abstract, an abstract fragment or > > > > > executable. > > > > > The default for this attribute is "no".' > > > > > > > > > > The definition of the abstractProcess attribute in > the schema > > > > > shall be > > > > > changed so as to allow for the values of 'yes', 'no' and > > > > > 'abstractFragment'. > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > > > > the roster of the OASIS TC), go to > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > > > > ave_workgroup.php. > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]