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

[James Bryce Clark <jbc@lawyer.com>]

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