ebBP 7/18/2005: Reminder TC Teleconference 19 July 2005: v2.0.1 CD

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

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: 3.4.9.3.3, 3.5.1