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: [Fwd: Re: [wsbpel] abstract process strawman]


Tony,
 
I really don't care what we call it but we clearly need to define the static checks we mandate above and beyond the schema.  
 
Satish

________________________________

From: Tony Fletcher [mailto:tony_fletcher@btopenworld.com]
Sent: Fri 10/1/2004 6:20 PM
To: Satish Thatte; 'Monica J. Martin'
Cc: 'Danny van der Rijn'; rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org
Subject: RE: [Fwd: Re: [wsbpel] abstract process strawman]



Dear Colleagues,

It seems to me that any discussion of conformance to the specification of
conformance to the (WS-BPEL 2.0) specification is now moot.  The TC decided
quite emphatically not accept my proposed issue which proposed to add
statements to the specification as to what artefacts can conform and what
those artefacts need to be / do to conform.  Thus conformance to the
specification is undefined and will deliberately remain so.  (And any claims
of conformance for anything to the WS-BPEL specification are meaningless, in
the sense that they can not verified or validated.)


 Best Regards     Tony
A M Fletcher

Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 amfletcher@iee.org       (also tony_fletcher@btopenworld.com)


-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: 30 September 2004 00:27
To: Monica J. Martin
Cc: Danny van der Rijn; rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org
Subject: RE: [Fwd: Re: [wsbpel] abstract process strawman]


Monica,

I think conformance to the specification is a separate issue -- it is more
like validation beyond just schema and this is what I would like to see us
use Issue 84 to solve.

As we have discussed before, there are multiple notions of conformance
between abstract and executable.  We are not going to forbid people
inventing new notions of conformance, including even notions of conformance
between two abstract processes in a use case of successive refinement.

What we should do is define some salient notions of conformance in the
specification, especially those where we believe we can contribute
sufficient technical content to make it worthwhile.  I believe that
behavioral conformance definitely fits in the latter category since it is
non-trivial to define, to say the least.

I do not believe we will mandate any implementation level requirements for
abstract-executable conformance verification, such as monitored conformance,
but I am open to being educated.

Satish



-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Tuesday, September 28, 2004 10:44 AM
To: Satish Thatte
Cc: Danny van der Rijn; rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org
Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman]

Satish Thatte wrote:

>I don't understand the distinction you are drawing when you write
>"guidance or compatibility between the abstract and one of the
adjoining
>executable processes rather than conformance".
> 
>
mm1: The latter infers more rigor and requirements on the
implementation. Guidance is only that - this is a best practice and
recommended that an executable process be conformant to an abstract one.

However, it's not dictated by the specification. Conformance, although
voluntary, infers that, for example, the mandatory functions of a
specification can be tested against in a verifiable way.  With the case
of abstract-executable, the conformance is two-fold - to the
specification and the executable to the abstract. Another discriminator
would be:

    * Monitored or passive: An executable process could be compatible
      with an abstract process. This could still support conformance of
      an abstract or executable process to the specification. It however
      does not require an executable process to be conformant to an
      abstract process. It could be recommended.
    * Active or directed: An executable process is evaluated to be
      conformant with an abstract process. The use of executable process
      could be constrained by the conformance to the abstract process.
      It also infers that the abstract and executable are conformant to
      the specification.

I am not supporting one over the other, but making the distinction as it

is relevant to this discussion and what it infers on implementations. Thank
you.


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/leave_workgroup.
php.





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