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 - 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]