Re: [ebxml-bp] ebBP 2/4/2005: Webber Questions (part 2 of 2)

["David Webber \(XML\)" <david@drrw.info>]

Monica,

Whether you say they are computable or not you still
need the section to indicate how they work!!!

And in any case - simply stating that the conditionals
should be boolean logicals is a modelling requirement
as well - eg that they concepts expressed need to be
named business rules that are logical booleans.

We need that.   Then we still have not described the
coupling mechanisms - those I did do the complete
design document for as part of ebContext - its ready
if people want to include that - but seems like you
want to hedge on that peice.  With or without that
the example I gave should be there I believe - otherwise
the text example that is there is very mumbo-jumboish
with no sense of how to exactly accomplish it.

We can discuss further.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "David Webber (XML)" <david@drrw.info>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Monday, February 07, 2005 8:01 PM
Subject: Re: [ebxml-bp] ebBP 2/4/2005: Webber Questions (part 2 of 2)


>
> >Webber: Monica,
> >OK - I went back and found the EndsWhen / BeginsWhen section.
> >
> >Now I'm thinking this part - Lines 1195 to 1202 is misleading - I
> >think we first need to state the principles of operation here:
> >
> >Current text: For endsWhen, in the care of a certification exam.  A
> >registrant is allowed three attempts to pass an exam to achieve
> >certification; otherwise the registrant fails. In an academic setting, a
> >health care provider, i.e. the registrant, attempts the certification
exam
> >three times. For the first try, the registrant submits a certification
> >request and engages in a registration step. The registrant request fails
and
> >is returned. The registrant increases insurance, retries and fails. For a
> >third try, the registrant increases staff capacity, then retries. The
> >registrant requests fails a third time. The registrant attempts to
> >re-register but must start over again. This scenario may apply to other
than
> >health care, such as Amazon self-registration.
> >
> >Insert before this after line 1194:
> >The beginsWhen expression MAY be used to:
> >
> >·         Link a semantic state (e.g. begins when "state" of
> >"product-delivered" is reached)
> >
> >·         Serve as a semantic definition that MAY be used to define that
> >state (e.g. "in the context of this BPSS, "product-delivered" is defined
as
> >the existence of both product-delivered date and delivery-signature)
> >
> >
> ===========
> mm1: Looking at Section 4.6.7.1, here's a try, David. You have to
> remember that we do not at this time render these as computable. They
> may be rendered computable by implementation (which you may have done?).
>
> FROM:
>
>  The beginsWhen expression MAY be used to:
>
> ·         Link a semantic state (e.g. begins when "state" of
> "product-delivered" is reached)
>
> ·         Serve as a semantic definition that MAY be used to define that
> state (e.g. "in the context of this BPSS, "product-delivered" is defined
> as the existence of both product-delivered date and delivery-signature)
>
> For endsWhen, in the care of a certification exam. A registrant is
> allowed three attempts to pass an exam to achieve certification;
> otherwise the registrant fails. In an academic setting, a health care
> provider, i.e. the registrant, attempts the certification exam three
> times. For the first try, the registrant submits a certification request
> and engages in a registration step. The registrant request fails and is
> returned. The registrant increases insurance, retries and fails. For a
> third try, the registrant increases staff capacity, then retries. The
> registrant requests fails a third time. The registrant attempts to
> re-register but must start over again. This scenario may apply to other
> than health care, such as Amazon self-registration.......
>
> A PreCondition indicates that the corresponding business activity MAY
> start only if the corresponding expressions are true. A PostCondition
> expresses a condition that MUST be true once the activity has been
> completed. For example, business Success is true (i.e. the status
> reported to the choreography is true) when the activity is completed.
>
> TO:
>  The beginsWhen or endsWhen expression MAY be used to:
>
> ·         Link a semantic state (For example, given the business
> collaboration definition, begins when or ends when may indicate when the
> "state" of "product-delivered" is reached.)
>
> ·         Serve as a semantic definition that MAY be used to define that
> state (e.g. "in the context of this BPSS, "product-delivered" is defined
> as the existence of both product-delivered date and delivery-signature)
>
> An example use case may be a certification exam.  A certification exam
> is expected to start when (begins when) a health care provider
> registers.  A registrant is allowed three attempts to pass an exam to
> achieve certification; otherwise the registrant fails. In an academic
> setting, a health care provider, i.e. the registrant, may attempt the
> certification exam three times.  For the first try, the registrant
> submits a certification request and engages in a registration step. The
> registrant request fails and is returned. The registrant increases
> insurance, retries and fails. For a third try, the registrant increases
> staff capacity, then retries. The registrant request fails a third time.
> The registrant attempts to re-register but must start over again, i.e.
> the certification exam ended when (ends when) the third attempt failed.
> This scenario may apply to other than health care, such as Amazon
> self-registration......
>
> A PreCondition indicates that the corresponding business activity MAY
> start only if the corresponding expressions are true. For example, a
> certification exam could not start unless a registration precondition
> exists. A PostCondition expresses a condition that MUST be true once the
> activity has been completed. For example, business Success is true (i.e.
> the status reported to the choreography is true) when the activity is
> completed. For example, a certifcation is closed only if the registrant
> passes or fails given the underlying criteria.
>
> >Webber: o    and expression must evaluate to a simple true / false
boolean
> >
> >An example of this would be:  beginsWhen="validOrderReceived OR
> >backOrderFulfilled"
> >
> >The conditionals themselves will be variables that have been defined in
the
> >BPSS variables section.  And associative expression then relates the
> >evaluation of the
> >
> >conditional.  In the case of the beginsWhen - this will normally
reference
> >an outcome from the preceeding BTA step.  In the case of an endsWhen -
this
> >will relate to
> >
> >current BTA step, and that BTA step will continue to iterate until the
> >endWhens is fulfilled, or the BTA fails (matching one of the guard
> >conditionals).
> >
> >So in the case described below the endsWhen is conditional on
> >endsWhen="certificationPassedOK", and the guard conditional is "Fail"
when
> >"retries>2 AND NOT certificationPassedOK".
> >
> mm1: David, I would suggest you bring this suggestion to the TC as these
> elements are not described as computable. We have not discussed how they
> could be used with variables. If I remember correctly (and would
> encourage your comment), we specifically asked you to consider this as a
> v3.0 feature (i.e. rendering these as computable and any association
> with variables such as those using an external specification). Thanks.
>
>
>
>