Re: [ebxml-bp] Tell 7/9/2004: Progress on AcceptanceAck and Variables to Support Your Episodal Memory Request

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

Monica,

Great notes - I believe we have resolutions to
99.9% of these items - and I have these implemented
already in the model I posted.

The only item I see outstanding is state management
external to BPSS - as discussed on the call yesterday,
and that is a V3.0 item.

See my notes below.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Anders W. Tell" <anderst@toolsmiths.se>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Friday, July 09, 2004 1:18 PM
Subject: [ebxml-bp] Tell 7/9/2004: Progress on AcceptanceAck and Variables
to Support Your Episodal Memory Request


> Anders,
> Per our lengthy conversation yesterday about variables and XPath to
> support what you called episodal memory (Reference:
> http://www.oasis-open.org/archives/ebxml-bp/200407/msg00014.html).
>
> Here is a brief summary of the current thinking. I should have more
> details later today from John Yunker on the variable capability
> referenced so stay tuned. This has been an action-packed session and
> I'll have some substantive notes before Monday's call, 12 July 2004.
>
> Work Item 39 Acceptance Acknowledgement
> V2.0 TECHNICAL SPECIFICATION CHANGES:
> 1. Define the role of the Acceptance Ack more clearly. Clearly
> differentiate technical vs. business state alignment using signals (for
> technical state alignment). Specify that signals have technical not
> business semantics. Receipt Ack is structural validation. Any contract
> formation should be part of a response. Acceptance Acknowledgement is
> content validation (guarantee is or will be processed).
=======
Somewhere we agreed to add "pending" to "accept" and "failure"
to states that a SIGNAL could indicate.  I believe this is enough - and
especially since when the signal is in a BTA - it is clearly in response to
an initiating send - see model example and tutorial PPT examples. ( If
we need more we could add some other status in addition to "pending"
but I believe pending is enough).
=========
>
> 2. Separate intent from the technical implementation. Rather than adding
> qualifiers on the Receipt Acknowledgement, use the QoS attributes. You
> can bind to QoS attributes that are related to Receipt Acknowledgment
> (i.e. to non-repudiation, authorization, document security and
> reliability) not the signal itself. This allows a legal community should
> certify technologies that are applicable for a specific jurisdiction.
========
Good - I believe the model and tutorial demonstrates these "named"
exchange profiles being used - eg normal, urgent, required, oneday, etc.
========
>
> 3. Add content validation to an existing signal RA.
========
????  Surely this is covered already with "business failure", and ability
to test endsWhen against either a signal or guard condition failure.
See tutorial and model - I think I have plenty of examples of this being
done.
========
>
> 4. Add a specificationtype for signal types (Could allow use of context).
========
OK.  I have this implemented in model, XML, and tutorial - and I posted
an email to list giving details of specifics on XSD changes et al and sample
instance.
========
>
> 5. Originally we discussed adding a signal purpose for signals. This was
> not accepted by the authors and they defer, at this time, to
> specificationType only.
========
Oh!  But we *need* this!!  See my example in the model and the email I
posted to list on signal processing.
========
>
> V3.0 TECHNICAL SPECIFICATION CHANGES:
> Consider late acknowledgement and the signal purposes.
>
> Work Item 55 - timeToPerform
> We can use the model representation that you sent Anders, if you can
> send me something I can copy into the technical specification.
========
I believe the ebContext method already solves this - see the
Technical note draft posted to list and Kavi - it exactly shows how
timeToPerform is managed.
========
>
> V2.0 TECHNICAL SPECIFICATION CHANGES:
> 1. Ensure text explains the timeToPerform element is maintained as a
> subelement of Business Collaboration (inherited to MPC and BC) and BTA
> type. TTP is allowed at every level and is placed explicitly at any
> level that a constraint applies.
========
I believe the ebContext method already solves this - see the
Technical note draft posted to list and Kavi - it exactly shows how
timeToPerform is managed.   Again - the model implements this too.

We could add this to the Tutorial to make it even clearer, under
an "Advanced Features and Techniques" section in the Tutorial.
========
>
> 2. Ensure the clear definition of a well-formedness rule related to
> timeToPerform: Business Collaboration timeToPerform has to be > than the
> smallest of the subordinate timeToPerforms.
========
OK.  That's more of an external business agreement level check on the
context instance and rules it contains - I'd say this was more of a
usage guideline than a normative rule however.
========
>
> 3. For dynamic aspects, use the new variable capability related to XPath
> that allows static or dynamic TTP. The expression could reference an
> external document, a variable value or information in a req-response
> document.
>
==========
Yep. The context mechanism of course allows you to explicitly point to
the document via a namespace declaration in the context instance.
==========
>
> DocumentEnvelopeNotation and Work Item 21 (Conditional Constraints:
> beginsWhen, endsWhen, and pre- and post-
> conditions)
===========
Again we can add more on this in Advanced section on Tutorial.  The model
example does show instances of how this works in tandem with context
mechanism and named conditionals that return binary true/false.
===========
>
> Also see Tell question on episodal memory - how does an invoice relates
> to an order - referenced above.
>
>     * Need exists to establish equality on the values of the business
>       documents involved (order to invoice) for correlation.
===========
Ugly - right now we have to assume this happens thru the BSI to the
external business application logic.  However JOIN can shield from
sequencing problems in this area - and also using a unique
THREAD-ID at the transport messaging envelope level.  See
the BCM Appendix B - linking and switching specification for details.
===========
>     * Use of XPath variables is a cleaner mechanism.
===== Yes!! Context mechanism is built around this. ======
>     * Need exists to more explicitly specify that the business documents
>       have a unique identifier. We need to express a name based on the
>       collaboration definition, to alleviate the ambiguity.
====== See note on THREAD-ID above =========
>     * Specify which are the parts of the exchanges that apply and map
>       out potential path expressions for the applicable instances. If I
>       am in a BC, put conditional aspects to allow to reach to other
>       parts of the BPSS.
======= Context mechanism does this already - see note above
about named conditionals - and then beginsWhen / endsWhen usage.
===================

>     * Need to have the business rules in computable not just textual
>       form. Wish to have the same view of the collaboration.
======== Answer - context mechanism uses XPath for this already =====

>     * Discuss further the support for use of OCL for DocumentEnvelope
>       Notation. In OCL, what is an object in BPSS? It is a document? If
>       it is like a 'purchase order', and when I exchange I send a
>       representation of state transfer and the 'purchase order'. How do
>       I establish the relationship between objects and documents? OCL
>       may not be capable of being used in BPSS unless we provide a new
>       specification section.
======== OCL is a dead, dead horse - lets not go there.  XPath as
noted above is the right answer.
==================
>     * Abstract the semantic from physical content. Populate the local
>       variable.
========= Local variables are supported in the context mechanism
already.
==========
>     * For post-conditions, conditional constraints allow the legal
>       community to bind into a logical document. This allows a community
>       to define their semantic content.
==========
Yes.  And the context mechanism supports this.  OK - this is the tenth
time + I've said this.  Seems to me - people either have to throughly
read and review the context mechanism technical note.  Or - we need
to have a dedicated day - say a two hour call scheduled - were we
step thru that document page by page.
==========
>
> v2.0 TECHNICAL SPECIFICATION CHANGES:
> 1. Resolve how we disambiguate the different BPSS instances that
> correlate, for example, an applicable invoice and order. Business
> documents have a unique identifier per instance as opposed to the
> message type only (nameID on the business document).

====== OK - model instance shows this usage.=====
>
> 2. Create a variable (which allows the definition of semantic elements)
> constructs (supports effective use of conditional constraints). This
> variable can be referenced by external elements such as UBAC.
>
======== Yikes!!! The context mechanism does this already - why do we
want two ways of doing things?  Also - if you lock this into the BPSS
instance,
everyone has to use the same ones - whereas putting it separately into a
context instance means you allow re-use of BPSS.
=============
> a. <variable name=originalPO
>
expression=document($placeorder.bta.requestdocument,"/message/order/@ordernu
mber>
> beginsWhen
>
expression='document($variables,"Variables/originalPO"=document($invoice.bta
.requestdocument,
> "/message/invoice/order/@ordernumber)
> b. Specify this is an abstraction of a type of information from the
> location in the document. We have a variable that can be bound to a
> particular location in a document.
> c. Express the boundaries of the use of XPath and the use of the
> variable in this and other related cases. Allow to set an XPath variable.
=========== Please read the context instance technical note document in
Kavi!!!! ==========
>
> v3.0 TECHNICAL SPECIFICATION CHANGES:
> 1. Investigate use of XPath v2.0.
>
> NOTE: THE SYNTAX AND USE CASES ARE BEING REVISED AND WILL BE SENT
TODAY!!!!
>
> Comments welcome. See you 12 July 2004!
>
>