Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding and Document References

["David RR Webber" <david@drrw.info>]

Anders,

A useful illustrative list - but I think it points up that what
is really going on here is that we need a generalized
mechanism.  For today it is TimeToPerform, tomorrow,
something else.

The context mechanism draft specifically allows you to
reference any element within the BPSS using
{namespace}:{XPath}.

The example assumes bpss is the namespace ID,
so we have:

 <condition name="bpss:timeToAcknowledgeAcceptance*" value="P10M"/>

and value denotes the replacement setting.  Of course you have an
optional conditional constriant to denote when this occurs - and
again that uses XPath expressions with namespaces to point to
the late binding needed (see Fgiure 3.2 in draft document).

Bottomline - I believe the context design mechanisms covers this
neatly and succinctly - using simple XML techniques - and follows
the BPSS model while extending it in a natural way.

Thanks, DW.

----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>
Cc: <martin.me.roberts@bt.com>; <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, January 27, 2004 1:13 PM
Subject: Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding
and Document References


> Dale,
>
> Its a complicated situation, but its clear that timeToPerform is needed
> however there are several "times" when timeToPerform  could/should be
> initiated or changed. A list of possible "times" may enrich and simplify
> the discussions in relation to current set of requirements.
>
> 1: in BPSS as default value - needed when you want to establish
> (industry) TradePractices. Here BPSS is reusable artifact that is
> related to a specific context (such as BusinessArea's, ProcessArea's ala
> Porter or SCORE). In order words it used by many legal entities.
>
> 2. in TPA as default value - needed when you want to establish bilateral
> TradePractices. This value overrides BPSS default value since agreement
> is established at a later stage
>
> 3. in Technical agreement such as CPA as default value - this value
> overrides TPA and BPSS value since agreement is established at a later
> stage.
>
> 4. in a negotiated BPSS that specializes an industry BPSS through
> negotiation process. This is done in the scope of a one more  UBAC,TPA,
CPA.
>
> 5. at the time of enactment/instantiation of a BPSS. Here a specific
> timeToPerform may be proposed by initiator and accepted by responder.
> Usually not a good idea to let the initiator unilaterally decide,
> especially if the timeToPerform really means delivery date.
>
> 6.a by exchanged business information in a transaction. TimeToPerform is
> extracted from exchanged document during  transaction enactment.
>
> 6.b by exchanged business information in a transaction. TimeToPerform is
> extracted dynamically by "invocing a method", "calling a function", etc.
> during  transaction enactment.
>
> 7. by referencing a "variable" that contains a duration value that was
> extracted from an enactment of transaction/completion of another
> transaction at an earlier point in time. I.e. first transaction sets a
> variable ttp="valueFromRespondingDocument" at transaction completion
> with success status
>
> 8. by the time of enactment,execution of a bootstrap transaction named
> "ChangeTimeToPerform(bpssInstanceID, transactionActivityID, 2h)". Here a
> change is proposed and subsecuently accepted or rejected
>
> ....
>
> 99. TimeToPerform in a BPSS is not really a constraint on the message
> exchange protocol but really a delivery-date constraint, that is, a real
> world event constraint. Possibly in conjunction with a PaymentUpFront
> business rule.
> However by putting a delivery-date constraint in a BPPS as TimeToPerform
> you get an approximation that both parties can live with.
>
> Have I missed any relevant time,mechanism?
>
>
> thanks
> /anders
>
>
> Dale Moberg wrote:
>
> >Martin writes:
> >
> >"Late Binding has some interesting and curious requirements.  We tried
> >to model the ordering process in BT.  We found that the use of the
> >overall TimeToPerform for a BinaryCollaboration was unworkable.  If I
> >have a PO that has a standard lead teim of 5 days do I set the TTP to 5
> >days?  But what happens if the customer does not want their goods for
> >30days.  The process would time out.  So I would like to treat all Times
> >and possible documents as being variables that may, but not necessarily,
> >be overidden by data sent within the Business Documents.  At the moment
> >there is lots of data that is passed between our customers that effect
> >the times and documents which we can not use as there is no way to
> >reference that information within the BPSS."
> >
> >Martin, I think you are joining other people who have commented that
> >TimeToPerform (and also TimeToAcknowledge) can be difficult to know how
> >to define at BP definition time. This makes me wonder whether they
> >should be optional to place in BPSS for cases where the time constraints
> >are known at design time? (Are there any cases of these?)
> >
> >In fact, the use cases being presented seem to suggest that
> >configuration time may also be too early to decide on these values (so
> >the CPPA really should also have some way to indicate that precise
> >values will be set at runtime). Would it still be useful to enter into
> >agreements on the "floor" or "ceiling" for these values? Would this
> >interval be a configuration aspect of a CPA agreement (or part of BPSS,
> >or in a UBAC agreement)? Is there any need to retain in CPPA or BPSS any
> >support for declaring values for these parameters?
> >
> >If it is runtime only, should it be part of Messaging headers? Or
> >possibly in business headers (such as those of ATG SBDH ?) Or both,
> >depending on which software components need to set or get the values.
> >
> >It seems to me that while these values certainly pertain to the business
> >process commitments, they are not clearly part of the design-time
> >machinery. It is difficult to know which software components need these
> >values, or at what layer of specification, the values that are used need
> >to be declared.
> >
> >I am sorry to be raising so many questions but those are ones that occur
> >to me while reading your remarks.
> >
> >
> >
> >
> >
> >
>
>
> -- 
> /////////////////////////////////////
> / Business Collaboration Toolsmiths /
> / website: <www.toolsmiths.se>      /
> / email: <anderst@toolsmiths.se>    /
> / phone: +46 8 545 885 87           /
> / mobile: +46 70 546 66 03          /
> /////////////////////////////////////
>
>
>
>