[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: final agreement on BPSS 1.0 model
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC