Re: 4-24 BPSS metamodel mtg (was: minutes, and new meeting call)

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

Jamie,
For the record:

In BPSS v0.90 DocumentEnvelope was the equivalent of UMM
objectflow+DocumentEnvelope, but it had an associated DocumentSet. 1-many
DocumentEnvelope->DocumentSet This gave us the capability of defining multiple
possible (but mutually exclusive) responses, even if they all use the same
DocumentEnvelope. This gave us capability to base choreography  based on
response type. 

In BPSS v0.99 DocumentFlow combined DocumentEnvelope and DocumentSet and
changed the cardinality from RespondingBusinessActivity to DocumentFlow to
1-many. This retained the capability of defining multiple possible (still
mutually exclusive) responses. This still gave us choreography based on
response type.

There is no new proposal for 1.0 to change DocumentFlow or its this
cardinality. Nor has there has been any such proposal that I know of. Nor has
there been any public issues raised about it. I don't understand your comment
about 5th bite of the apple ....

However, in the spirit of alignment we are discussing whether we can change
the name of DocumentFlow to DocumentEnvelope so we have the same name in UMM
and BPSS. I don't support that namechange, however, unless it results in the
semantics are also the same. So let's just look at what needs to change (or
whether we just agree to disagree).

-karsten




>I have the following comments on Karsten's report of today's preliminary
>decisions.   I agree with many of his descriptions, except as noted below
>in cases where I think the report needs re-examination.   We all owe
>Karsten gratitude (and probably a beer in Vienna) for the sheer amount of
>drafting work he has shouldered.  
>
>At 11:52 AM 4/24/2001 , Karsten Riemer wrote:
>* * *
>> 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.  * * *
>
>> 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
>
>Our conversation about UMM alignment led to several of these 'subject-to'
>notes.  In my view, each indicates that we would like to make the change,
>but only if Jim C or some other N90 expert tells us we won't fall out of
>alignment.    
>
>>   Additional alignment needed: isIntelligibleCheckRequired on 
>>   responding only?
>
>Yipes, let's talk about it Wed.
>
>No comments on 2 or 3
>
>> 4. Security Parameters (issue 57)
>>   Resolution: drop isSecureTransportRequired from business 
>>       transaction level altogether
>>   Resolution: Do NOT [change] boolean to Persistent/Transient/No
>>   Subject to: UMM to remove isSecureTransportRequired from
>>       transaction level
>
>FYI, this adopts my suggestion was that (1) the parameter is an
>inappropriate composite of several risks, each of which is better addressed
>by individual toggles we have elsewhere, and (2) if UMM wants to retain
>this composite, we should include it but deprecate it.  
>
>No comments on 5 or 6, except to note that on 6, we may try to add some
>explanatory text relating to the practical problems of unique name
>generation.  
>
>>7. Document Envelope (issue 120, #3)
>>
>>   Proposed Resolution: Rename DocumentFlow to
>>       DocumentEnvelope AND align the attributes and semantics to be 
>>        identical UMM and BPS. 
>
>I agree.  That's what we discussed.   But see the following.
>
>>   If we cannot align semantics we are better off with two separate
>>        names.
>
>I don't think we achieved any resolution as to that.    
>
>>   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. 
>
>The above 10 or so lines, starting with "NOTE", were not discussed today,
>and are utterly free of consensus.   This appears to be a return to
>comment number 124 in the current log (which at one time was inaccurately
>attributed to me), proposing that responses may be related  many-to-one, as
>well as one-to-one, to a request.  If I understand it correctly, this is
>approximately the fifth bite at the apple for the "Son of EDOCS" position
>which we keep debating, resolving as rejected, and then revisiting.    
>
>At this point a long re-hash of prior arguments is probably not
>appropriate.  Suffice it to say that in my view (again, if I understand
>what is proposed here) the change would break the validity of the model's
>fundamental business signal structure that allows for fairly deterministic
>formation of contracts.   
>
>>   DocumentEnvelope to have the following attributes:
>>   isPositiveResponse, isConfidential, isTamperProof, isAuthenticated
>
>Please note the above.   We discussed that we need to add a brief
>explanation of the use of 'positive response' .   Also, we should confirm
>whether the three 'security' parameters at the lower document level
>override those at this higher envelope level.   As to the latter, I think
>they should (finer granularity overrides).   Any other views?
>
>> 8: New renaming issues (from BPE work):
>>   Resolution: Rename Requires->Precondition and ResultsIn-
>>        PostCondition
>>   Subject to: UMM to rename Preconditions->Precondition
>>        PostConditions->PostCondition
>
>We discussed this, but  I do not believe that we agreed to rename, or to
>require that UMM change the plural to singular.  Those were one person's
>suggestions.  Our resolution was, I thought, a decision to ping Jim C or
>another N90 expert to confirm whether the distinctive object names,
>e.g."requires", should be retained, or changed to use the N90 names, e.g.,
>"precondition", in view of the apparent difference in datatypes between N90
>and BPSS.   
>
>No comments through the end.  
>
>Regards   Jamie Clark
>- - - - -
>James Bryce Clark
>Spolin Silverman & Cohen LLP 
>310 586 2404    jbc@lawyer.com  
>
>