[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 99 - Some proposed wording
I view the abstract process fragment identifier as serving the same purpose as a XML Schema does for a XML message. It provides framing for what the message can look like. So the abstract process fragment identifier is only redundant if XML schema is. I would have to disagree with your assertion that BPEL provides two types of process with clear semantics and syntactic differences. If this were so then we would not have had to create a dedicated abstract process sub-group whose only purpose is to figure out exactly what abstract processes are for. The existence of the sub-group demonstrates that our current taxonomy is not sufficient. I am proposing a way to make it more sufficient. Yaron Trickovic, Ivana wrote: > > > 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]