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,

I still disagree with you in a few points and would like to suggest to resume this discussion as soon as the sub-group publishes first results. I hope we will have a solid basis for a constructive discussion.

Kind regards,

Ivana

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Freitag, 21. Mai 2004 18:59
> To: Trickovic, Ivana
> Cc: wsbpel@lists.oasis-open.org
> 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]