[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: minutes, and new meeting call
Today the list servers were not working, so very few people showed up at metamodel meeting, and those who did had not seen the agenda. So we will have a make-up call tomorrow 4/25 at 1 pm Eastern, call in 888-699-0348 pass code 3042#. In tomorrows meeting we will ratify todays decisions, and if we do then we can institute the "model freeze" that Jamie Clark called for. I do agree that such a freeze is overdue. I disagree with several other statements made by Jamie but will take that up with him 1-on-1. Here are the decisions from today (4/24): (We will move forward with these decisions unless counter proposals are made before tomorrows 1 pm Eastern time meeting. Note that the majority of them are depending on UMM also changing. If that doesn't happen there is no sense in trying to align on those issues.) 1. Transaction parameters (issues 131, 132, 119, 12) Resolution: Retain UMM transaction constraint, Resolution: move timeToAcknowledgeAcceptance and isNonRepudiationOfReceipt to requesting activity Subject to: UMM move timeToAcknowledgeAcceptance to requesting activity Additional alignment needed: isIntelligibleCheckRequired on responding only? 2. Synchronous (issue 40, 58) Resolution: Drop attribute isSynchronous and all associated text Subject to: 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 Comment: UMM is unclear about meaning of this attribute, BPSS already provides a fork to establish concurrent activities, is this different? 4. Security Parameters (issue 57) Resolution: drop isSecureTransportRequired from business transaction level altogether Resolution: Do NOT cahange boolean to Persistent/Transient/NO Subject to: UMM to remove isSecureTransportRequired from transaction level 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. Subject to: This should be a UMM attribute as well, on DocumentEnvelope, see below. 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. 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) 8: New renaming issues (from BPE work): Resolution: Rename Requires->Precondition and ResultsIn->PostCondition Subject to: UMM to rename Preconditions->Precondition PostConditions->PostCondition 9. Completion vs. Termination Resolution: rename TerminalState to CompletionState Other discussion: Reconfirmed that we will include a W3C schema version
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC