Tell 7/9/2004: Progress on AcceptanceAck and Variables to Support YourEpisodal Memory Request

["Monica J. Martin" <Monica.Martin@Sun.COM>]

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).

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.

3. Add content validation to an existing signal RA.

4. Add a specificationtype for signal types (Could allow use of context).

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.

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.

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.

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.

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.


DocumentEnvelopeNotation and Work Item 21 (Conditional Constraints: 
beginsWhen, endsWhen, and pre- and post-
conditions)

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.
    * Use of XPath variables is a cleaner mechanism.
    * 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.
    * 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.
    * Need to have the business rules in computable not just textual
      form. Wish to have the same view of the collaboration.
    * 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.
    * Abstract the semantic from physical content. Populate the local
      variable.
    * For post-conditions, conditional constraints allow the legal
      community to bind into a logical document. This allows a community
      to define their semantic content.

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).

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.

a. <variable name=originalPO 
expression=document($placeorder.bta.requestdocument,"/message/order/@ordernumber> 
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.

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!