decisions made with Jim today

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Here are the decisions from today (4/25):

Jim Clark attended most of the meeting, and gave us the historical and UMM
perspective that we needed in order to ratify yesterday's decisions as
follows:

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)


The following is NOT finally resolved. Jim is reviewing this and unless we
come to agreement tomorrow, this will not change from the BPSS v0.99.

7. Document Envelope (issue 120, #3)

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

   If we cannot align semantics we are better off with two separate names.

   NOTE that we had overlooked cardinality misalignment in today's meeting

   Semantic alignment: 
   Exactly 1 DocumentEnvelope from Requesting to Responding
   Zero or N possible DocumentEnvelopes from Responding to Requesting.
   (This mean you can specify more than one possible, but at runtime thate is
always at
   most 1) 
   DocumentEnvelope to have one and only one primary BusinessDocument,
   and any number of Attachments. 
   DocumentEnvelope to have the following attributes:
   isPositiveResponse, isConfidential, isTamperProof, isAuthenticated

   Subject to: UMM to ensure that ObjectFlow is never modeled independently,
   i.e. that a modeler never has to assign a name or any other attritube value
to an ObjectFlow, only to the DocumentEnvelope.

   Related note: I think I see why we cannot align, because UML does not allow
more than one classifier for an object flow, and then we cannot get the
cardinality aligned, suggestion, just model more than one object flow)