[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 9/8/2004: Additional Issues Discussion Friday 10 September (seeherein)
In order to complete some of the work items, I'd asked last week for a special call this week. This session will piggy-back off the end of the CPPA call Friday, 10 September 2004, 9 a.m. PDT. Here is a start of work items to resolve (propose recommendations for TC). Note, I'll be sending another round tomorrow, Thursday, 9 Sept. Thank you. ::::::: Call in details are: 877 204 8750, passcode 480 627 2648 Dale if there is an international extension, please advise. ::::::: Work Items ++++++++++ Pattern attribute (Not logged as a work item, included in WI-19): The 'pattern' attribute exists on: BusinessCollaborationType, BusinessTransactionType, BinaryCollaborationType and MultipartyCollaborationType. With the inclusion of the 'concrete' business transaction patterns, this attribute could be considered as redundant. Two options were identified: (1) Allow it to be used if the 'concrete' patterns are not, and provide a developer's hint. Downside on this option is that the attribute could reference back to a URI based on different semantics, or 2) Delete the 'pattern' attribute and allow extensibility in the concrete BT pattern. This could encourage/require the implementation use the patterns or extend them, and allow new requirements such as those from UBAC. Proposal: Delete 'pattern' attribute and allow extensibility in the concrete BT pattern. References: 9 August 2004 TC minutes, http://www.oasis-open.org/archives/ebxml-bp/200408/msg00027.html 28 July 2004 summary, http://www.oasis-open.org/archives/ebxml-bp/200407/msg00131.html =========================================================================================================================== WI-71, isLegallyBinding: While we anticipate more metadata requirements from UBAC, LegalXML and other venues where contractual or legislative obligation reside. Our goal in v2.0 is to more accurately identify the attribute with that understanding and looking for business/legal guidance on any other substantive changes. In addition, Jamie Clark has promised a short summary regarding Digital Signatures so we can consider this in any action. Proposal: Rename isLegallyBinding attribute on the BusinessTransactionActivityType to HasLegalIntent. References: 28 July 2004 summary,http://www.oasis-open.org/archives/ebxml-bp/200407/msg00133.html Detailed response Kelly Ray (LegalXML), http://www.oasis-open.org/archives/ebxml-bp/200408/msg00082.html and http://www.oasis-open.org/archives/ebxml-bp/200408/msg00077.html Response from Messing courtesy of Sally St. Amand, http://www.oasis-open.org/archives/ebxml-bp/200408/msg00047.html =========================================================================================================================== WI-4, Mapping to other ebXML specifications v2.0 identified discussion items: Name-NameID (in work), OperationsMapping (in work), isLegallyBinding (in work), MSI/BSI, validation parameters (ebMS v3.0 issue related to payload), services (Action-Service) [relates in part to Operations Mapping]. This should actually be discussed either jointly with other ebXML TCs or through the Joint Committee (JC). Proposal: Map what we can accomplish and complete list of joint-resolution work items that should be considered by the other TCs or JC (to coordinate with the other TC). Action: Assign champion once schema is complete. =========================================================================================================================== WI-5 Well-Formedness Rules Courtesy of editors' particularly Dale, here is a starting set that needs your input: a. No stateless collaborations. b. An outer collaboration TTP has to be as long as the longest inner collaboration. c. Within any collaboration, there must be at least one state defined. A state is either a BTA, complexBTA, or CollaborationActivity. d. Links (FromLink/ToLink) should not reference linking constructs. e. Linking constructs must reference states in collaboration (Start, Transition, Fork, Join, and Decision). f. A Performs is not required if only two parties are involved (need verification from Dale). No proposal yet. Need input. Reference: Dale's input, =========================================================================================================================== WI-39 Acceptance Acknowledgment The current Acceptance Acknowledgment has resulted in some confusion/concern in the legal community. Anders Tell has proposed that we separate this acknowledgment from the broader scope of contract formation referenced in the UMM (notifications of acceptance leading up to an acceptance of a commitment, Chapter 8). This allows a party to act on when received. While we (ebBP) team await further metadata/business/legal requirements from UBAC, we understand this acknowledgment can: a. Include content validation. Separate intent from the technical implementation. b. Provide technical semantics. Any contract formation is outside of this acknowledgment. Additional Proposal (in addition to editors' F2F): 1. Utilize text in reference from editors' F2F to further explain this acknowledgment. 2. Specify in technical specification that more work is being defined on acceptance (as referenced above) and contract formation and the requirements are anticipated. 3. Change signal name to BusinessAcknowledgment. References: Editors's summary, http://www.oasis-open.org/archives/ebxml-bp/200407/msg00035.html Moberg questions, http://www.oasis-open.org/archives/ebxml-bp/200407/msg00144.html Tell summary, http://www.oasis-open.org/archives/ebxml-bp/200408/msg00002.html ========================================================================================================================== WI-59 Signals (Addl Transaction Support) (Schema related question only) We have defined consistent signal structures that map to document and document envelope. We include Specification and ConditionalExpression elements. Dale Moberg has raised two questions: a. If these elements are needed. b. Should we allow the schema for the content model to be included (raising the visibility to the signal structure). Proposal: Dale can discuss this item and suggest options. Reference: Email sent 8 Sept 2004 by Martin ========================================================================================================================== New Work Item WI-77 isIntelligibleCheckRequired Serm Kulvantunyou has asked if the attribute could be placed with the Receipt Acknowledgment (RA). A similar subject was raised in the editors' F2F in July if any content validation could be associated with the RA. Currently, the attribute is defined on the Requesting and RespondingBusinessActivity. Serm has raised (and we have another work item against) the multiple validation levels that could apply (relates to Work Item 39). It is apparent that some of this may result, in the future, in metadata requirements from other venues like UBAC. The actual requirements map back to the UMM R10 Chapter 8, reference: "Both partners agree that a responding partner role must check that a requesting document is not garbled (unreadable, unintelligible) before verification of proper receipt is returned to the requesting partner. Verification of receipt must be returned when a document is “accessible” but it is preferable to also check for garbled transmissions at the same time in a point-to-point synchronous business network where partners interact without going through an asynchronous service provider." No proposal at this time. Discuss briefly in special session in 13 Sept 2004 call. References: Thread with Serm, http://www.oasis-open.org/archives/ebxml-bp/200409/msg00026.html Martin original post, http://www.oasis-open.org/archives/ebxml-bp/200408/msg00046.html ==========================================================================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]