[Fwd: [ebxml-bp] ebBP 7/18/2005: Reminder TC Teleconference 19 July2005: v2.0.1 CD and Timing Questions

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

Note the timing questions we will discuss. Thanks.

> mm1: In preparation for tomorrow's call, the 6 packages for the 
> Committee Draft Candidate were uploaded late last week and, finally 
> the technical specification 17 July 2005.
>
> Packages:
> 1. Spec: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00037.html 
>
> (Word html [.mht] version: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00038.html) 
>
> 2. Schema: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13626 
>
> 3. Schema, Descriptive Name: SignalSchema: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13628 
>
> 4. Documentation, Descriptive Name: Schema: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13631 
>
> 5. Documentation, Descriptive Name: SignalSchema: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13630 
>
> 6. Documentation, Descriptive Name: Supplements: 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13629 
>
>
> Please look over the six packages particularly the core schema and 
> technical specification. In the technical specification, editorial 
> changes have been made for consistency across different sections (such 
> as where changes were made and a related one needed to be implemented 
> in another section such as for shared intent in Section 3.4.2). In 
> addition, a few sections specified 'is required,' 'needs to comply,' 
> and similar language; the verbiage was updated to reflect appropriate 
> RFC 2119 language (MAY, MUST or SHOULD). Please review these sections 
> (pages 20, 23, 31, 34, 58, 60 and 68 - changes visible in diff06 copy).
>
> I have posted both diff and revised copies of Working Draft revision 6 
> for review in Microsoft Word and Word .html format (.mht for Microsoft 
> Word 2003). I am attempting to generate .pdf but the technical 
> specification is very large and taxing the generation process. Will 
> continue to try to make this work, and if need be will separate the 
> examples into a separate appendix document file, which may assist in 
> generation and download requirements.
>
> Dale, please verify the change of performsRoleRef note (second one) to 
> @nameID not @name in Section 3.8. Most if not all of the referential 
> constrains are related to the use of @nameID so I believe this change 
> is correct. Need you to review to verify my assumption.
>
> Finally, a few open questions found during detailed specification 
> editing that I will raise tomorrow regarding timing parameters. I 
> apologize for not posting sooner
> but T1 links were down in my area and I didn't have any email (and 
> limited phone) access until just now (~4 p.m. PDT). In earlier 
> versions of ebXML BPSS, some revisions were made regarding use and 
> priority of TimeToPerform, and AA and RA timing. Any decision ebBP may 
> consider may require minor updates to the technical specification.
>
> Possible points to consider clarification:
> 1. Clarify the priority of signals.
>
> Here are some of the previous version related sections:
> v1.05: When the time to perform an activity equals the time to 
> acknowledge receipt or the time to acknowledge business acceptance 
> then the highest priority time out exception must be used when the 
> originator provides a reason for revoking their original business 
> document offer. The time to perform exception is lower priority
> than both the time to acknowledge receipt and the time to acknowledge 
> business acceptance.
>
> v1.1: The total time allowed for a business transaction activity to 
> complete is therefore, timeToPerform plus the timeToAcknowledgeReceipt 
> on the response, and the timeToAcknowledgeAcceptance on the response. 
> Additionaly, timeToPerform must be greater than the sum of 
> timeAcknowledgeReceipt and timeToAcknowledge Acceptance and the request.
>
> .....Typically, the TimeToPerform is a higher priority than Acceptance 
> Acknowledgement, which is a higher priority than Receipt 
> Acknowledgement. Process (signal) timeouts are recoverable within 
> retry parameters and not recoverable outside of the retry parameters.
>
> [Note: This was actually added in v1.1 after significant discussion 
> with special BPSS team in UN/CEFACT, and retained in v2.x.]
>
> Reference in inputs to UMM:
> When the time to perform an activity equals the time to acknowledge 
> receipt or the time to acknowledge business acceptance then the 
> highest priority time-out
> exception must be used when the originator provides a reason for 
> revoking their original business document offer. The time to perform 
> exception is lower
> priority than the time to acknowledge business acceptance, which is in 
> turn lower priority than the time to acknowledge receipt.
>
> [Editor's note: For 2.0.1, Sections 3.6.1, 3.6.2.3]
>
> 2. Timing parameters
> a. Clarify sum of times between timing parameters.
> b. Do we need to further specify the case where TimeToPerform equals 
> TimeToAcknowledgeAcceptance and a Response Business Document applies?
>
> v2.0/2.0.x: The total time allowed for a BTA to complete is therefore, 
> TimeToPerform that is equal to or greater to the 
> timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance on the 
> Response (given which are used). Additionally, TimeToPerform for that 
> BTA MUST be greater than the sum of timeAcknowledgeReceipt and 
> timeToAcknowledgeAcceptance and the Request.
>
> [Editors note: For 2.0.1, Sections 3.4.9.3.3, 3.6.1, 3.6.2.1, 3.6.2.3 
> and 3.6.3]
>
> 3. Clarify logical occurrence.
> Which is true or do we need a qualifier on Section 3.5.1 (logically 
> handoff controls in discrete manner)?
>
> Section 3.4.9.3.3
> Based on any agreement between the parties, the requesting party 
> typically MAY recognize that the Business Document had been
> successfully received and processed. Where applicable and used, the 
> logical sequence of the Receipt Acknowledgement,
> Acceptance Acknowledgement and Response are based on the timing 
> expectations defined. For example, in implementation,
> if an Acceptance Acknowledgement is received prior to a Receipt 
> Acknowledgement, the requesting party may wait (if no
> timeout), for the Receipt Acknowledgement because the two Business 
> Signals are handled by different systems.
>
> Section 3.5.1
> • Control will be returned back to the Requesting Activity if either a 
> ReceiptAcknowledgement and/or AcceptanceAcknowledgement and/or a 
> Response are specified as required. A ReceiptAcknowledgement (if 
> required) MUST always occur before an AcceptanceAcknowledgement (if 
> required), and an AcceptanceAcknowledgement MUST always occur before a 
> Response (if required). Control is returned to the Requesting Activity 
> based on the last required of these three (if any). If none required, 
> control stays with the Responding Activity.
>
> Editor's note: For v2.0.1, Sections 3.4.9.3.3, 3.5.1