For Tues mtg - short - re REA

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

In the BP SS, there are an awful lot of things going on.  I'm a lawyer, so
I get to ignore the hypertechnical ones.  :)   Here are the ones I care about.
A.   REA
B.   Collaborations as a contract-making device
C.   ACK
This message is about REA.  Another is coming about collaboration.   I am
going to hod my fire on ACK until I hear more today.  

There are a number of attractive features to Bill McCarthy's REA principles.  
To the extent feasible, I think our BP model should be REA-compliant.

I think "feasible" means 

     1.     We should only do things in 1.0 that we can thoroughly
understand between now and March 19th.  This is a pretty severe constraint.

I think "REA-compliant", as so limited, means

     2.      The model permits REA-compliant transactions --- makes them
achievable (permissive).  In other words, a model that forces REA
associations on every transaction (mandatory) is beyond us,

If that's right, here are the level of requirements that I think apply.    

      3.   We should not do anything with "actors" and "roles" that
prohibits a correspondence with REA "economic actors" and "economic units".   

     4.     We should permit an atomistic transaction to address specific
"economic resources".   

     5.     We should permit rudimentary assembly of "economic contracts."

     Comment on progress on 3:   I think the current BPSS doesn't have a
lot of problems here.  Perhaps we need to permit roll-ups of actor objects,
so that even a simple collaboration handler  recognizes that "Karsten" and
"Jim" are both instances of "SpecSchemaEditorGuy" authorized within a
SpecSchema collaboration to write to the master draft.   I raise this as a
question.  Do we need more "IsAuthorized" functionality than we have at
this time?  

     Comment on progress on 4:   This is a constraint on the identity of
objects populating core components, and requires a "recommendation" that BP
SS model users design transactions around functions [raw materials
purchase], not ossified business departments [purchasing department].  The
point is to align that the "objects" manipulated by ebXML transactions to
correspond relatively easily to the "objects" manipulated by your
ERP/EAI/CORBA whatever.  What else, if anything, is necessary in the BP SS
to achieve this? 

 James Bryce Clark
Spolin Silverman & Cohen LLP 
310 586 2404    jbc@lawyer.com