OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: final agreement on BPSS 1.0 model

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

   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
   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

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
   Resolution: retain isIntelligibleCheckRequired where it is at
BusinessAction level

   This all based on Jamie and Jim both agreeing that it makes sense to allow
   to independently require a signed and/or intelligibleChecked receipt
   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
   Resolution: Do NOT cahange boolean to Persistent/Transient/NO
   Document that the bolean value TRUE requests 'persistent' security, FALSE
   no security

   Jim Clark had some hesitation based on some historical issues. Unless Jim
   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
   and will be of type "expression". It is merely the responders assertion of
   constitutes a positive response, it is not by itself a determinant of
   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

   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

There are no remaining identified issues.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC