[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Tell 7/9/2004: Progress on AcceptanceAck and Variables to Support YourEpisodal 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). 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!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]