RE: final agreement on BPSS 1.0 model

["Kanaskie, Kurt A (Kurt)" <kkanaskie@lucent.com>]

All,

Attached are the V1.00 versions of the DTD, XSD and examples. Sorry for the
delay, travel logistics and bandwidth prevented me from getting these out
earlier, its been quite a ride!


 <<BPSS_XML_V1.00.zip>> 
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
kkanaskie@lucent.com
(610) 778-1069 Note the new number!

 -----Original Message-----
From: 	Karsten Riemer [mailto:Karsten.Riemer@east.sun.com] 
Sent:	Thursday, April 26, 2001 4:25 PM
To:	ebxml-bp@lists.ebxml.org
Subject:	final agreement on BPSS 1.0 model

 << File: Word.Document.8 >> Here are the BPSS decisions from today (4/26) 
All of these are final for version 1.0 and will be reflected in a document
1.0B to be sent out tonight.

(resulting uml class diagram attached, only change from this morning is
DocumentFlow rename to DocumentEnvelope)

Jim Clark attended the meeting, and we came to a conclusion on the last
issue
remaining from yesterday:

7. Document Envelope (issue 120, #3)

   Proposed Resolution: Rename DocumentFlow to DocumentEnvelope AND align
the
attributes and semantics to be identical UMM and BPS. 

   There was agreement to go ahead with this renaming, AND to move UMM
towards
alignment

   Jim Clark to promote with TMWG the following semantic alignment: 

   Exactly 1 DocumentEnvelope from Requesting activity to Responding
   Zero or N possible (but mutually exclusive) DocumentEnvelopes from
Responding 
   activity to Requesting.
   DocumentEnvelope to have the following attributes:
   isPositiveResponse, isConfidential, isTamperProof, isAuthenticated

   (This mean you can specify more than one possible response
DocumentEnvelope
at designtime, but at runtime there is never more than one sent from
responder
to requestor)
   DocumentEnvelope to have one and only one primary BusinessDocument,
   and any number of Attachments. The way to show this on a
BusinessTransactio
activity diagram is to have multiple object flow symbols and annotate them
as
mutually exclusive)



We also discussed signal alignment.
Jon Yunker and Jamie Clark will draft a proposal for alignment. 
If we can get that agreed by BP list by tomorrow night, it will be in 1.0,
otherwise BPSS v1.0 signal definitions will be unchanged from BPSS v0.99


The remaining issues stand as ratified yesterday:
(Jamie to supply some supporting text for guaranteed delivery, and
isPositiveResponse)

1. Transaction parameters (issues 131, 132, 119, 12)

   Resolution: Retain UMM transaction constraint, 
   Resolution: move timeToAcknowledgeAcceptance to requesting activity
   Resolution: retain isNonRepudiationOfReceipt where it is at
BusinessAction
level
   Resolution: retain isIntelligibleCheckRequired where it is at
BusinessAction level

   This all based on Jamie and Jim both agreeing that it makes sense to
allow
responder 
   to independently require a signed and/or intelligibleChecked receipt
acknowledgement, 
   as long as it does not change the requirement that the transaction ends
upon receipt
   of response, not upon receipt of receiptAck.

   Jim Clark will ask TMWG approval to amend UMM accordingly: 
   UMM move timeToAcknowledgeAcceptance to requesting activity
   UMM move isNonRepudiationOfReceipt to BusinessAction
   UMM move isIntelligibleCheckRequired to BusinessAction


2. Synchronous (issue 40, 58)

   Resolution: Drop attribute isSynchronous and all associated text

      Jim Clark will ask TMWG approval to amend UMM accordingly: 
      UMM removes text about synchronous at line 1009 and 1032/1034
      (there are other references to synchronous in BSV, but that layer is
non
in scope for       ebXML)

3. Concurrent (issue 111): 

   Resolution: Retain attribute isConcurrent and all associated text

      UMM is unclear about meaning of this attribute, we believe it is for
concurrent             instances of the SAME transaction and as such
different
from fork. 
      BPSS will reflect it as such and distinguish it from fork.
      It should be clarified in UMM as well.

4. Security Parameters (issue 57)

   Resolution: drop isSecureTransportRequired from business transaction
level
altogether
   Resolution: Do NOT cahange boolean to Persistent/Transient/NO
   Document that the bolean value TRUE requests 'persistent' security, FALSE
requests 
   no security

   Jim Clark had some hesitation based on some historical issues. Unless Jim
gets 
   back to us by end of tomorrow's meeting, this decision stands, regardless
of what
   UMM decides to do.

   Related issue: we will retain the isGuaranteedDeliveryRequired as a
boolean
at Business Transaction Level, and document that it is just an instruction
to
CPA negotiators to pick a reliable channel.

5. Legal (issue 134, 29-31, 42) Jamie's recommendations

   Resolution: Retain word isLegallyBinding, tighten text
   Resolution: Change word isSuccess to isPositiveResponse. Attribute will
be
optional
   and will be of type "expression". It is merely the responders assertion
of
what
   constitutes a positive response, it is not by itself a determinant of
overall 
   transaction success.

   Jim Clark liked this isPositiveResponse concept and will pursue it
relative
to UMM

6. Xpath/ID (issue 76)

   Resolution: Adopt Kurt's proposal 5

   Need to work examples of how to reference by concatenated name and/or by
ID
   We recommend but cannot require use of Global ID's.

   Note: this will eliminate need for concatenated tags
(BinaryCollaboration+AuthorizedRole)

   This is not a UMM related issue.

8: New renaming issues (from BPE work):

   Resolution: Rename Requires->Precondition and ResultsIn->PostCondition

   Jim Clark to explore UMM alignment: 
    UMM to rename Preconditions->Precondition PostConditions->PostCondition

9. Completion vs. Termination 

   Resolution: rename TerminalState to CompletionState
   (this is a UML diagram only issue, DTD does not have this element as it
is
abstract)


There are no remaining identified issues.

BPSS_XML_V1.00.zip