quick update from metamodel team

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

In today's meeting:

We synced up the pictures:
Core will send out a new picture.
Jim, could you send out a picture with the 'Performs' class explicit,
that is more compliant with MOF which doesn't support associaton classes.
Also add in the two associations from BusinessActivity directly to
AuthorizingRole, that is required if you are to enforce the constraint that
all transactions within  a binary collaboration have the same two roles.

We discussed feedback from TP on DTD alignment.
One was a concern that we had too many places to override security/timing
parameters. Cory will remove that from all levels above business transaction.
Karsten will revise the table of relevant control parameters so TP can have a
last word in whether they think they are all business paramters or some of
them implementation parameters.

We discussed document structure. A proposal from TP team about a 'document
set' in between the DocumentEnvelope and the Document. Sounded like it solved
several issues. Cory felt it was an unnecessary level for times when you only
have one document (which might be most of the time). Cory will put a recursion
on business document and make the 1-1 envelope to document constraint
explicit.

Discussion on whether we need transitions directly on requestingActivity. 
We read and understood Jim's 5 points and agree that we do not want to loose
any of the 5 'functionalities' listed, but strongly feel that transitions at
transaction level fully preserve these 'functionalities'.
Karsten to check with RosettaNet architects for their opinion.
The 5 'functionalities' are:
1. be able to specify a business transaction outside the scope of a
collaboration 2. be able to state terms and conditions (i.e. REA?) directly
against a BT 3. BT is an atomic unit of execution (in business terms)
4. Specification must support Core Process team
5. Specification must support PIPS
Again we strongly disagree that you must have transitions on requesting
activity to achieve this, there is always 1 and only one requesting activity
for a transaction, and it is always the first step in the transaction,
therefore all guards on the transaction are implicitly guards on the
requesting activity.

But, I just realized what Jim's comments mean, and I agree that we need
something  that specifies the universal guards on the transaction definition,
in addition to the USE of the transaction in a collaboration. But I strongly
insist, again, that this be at transaction level, not requesting activity
level. 

On the .doc spec document, Karsten has sent out one set of edits. Karsten and
Jim  will tag team to complete this by tomorrow.

For tomorrow's meeting:
Final Agreement on guards on transaction vs. transaction use
Final Agreement on list of control parameters and their placement in
classes and in DTD.

Same call in info:
12 noon Friday 12/22
To access the calls,
dial 888-699-0348 domestically and  +1 732-336-6000 internationally, with a
PIN of 3042#.  


-karsten