RE: quick update from metamodel team

[Cory Casanave <cory-c@dataaccess.com>]

Enclosed are the updated artifacts (model, DTD, sample, change notes) to
reflect results from the 12/21 meeting.
 <<ebXmlSpec082.zip>> 
The following are the changes:
After 12/21/00 Meeting (Revision 0.82)
1.	Removed "retry Count"
2.	Added abstract terminal state
3.	Added sync state to model and DTD
4.	Timing and security  should only apply to business transaction
5.	Change Document Transition Vehicle to Business Signal
6.	Fix document/signal/status cardinality

Item to do - Add document model, need input from JJ on CC model.


> -----Original Message-----
> From:	Karsten Riemer [SMTP:Karsten.Riemer@East.Sun.COM]
> Sent:	Thursday, December 21, 2000 2:24 PM
> To:	ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
> Cc:	cory-c@dataaccess.com
> Subject:	quick update from metamodel team
> 
> 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

ebXmlSpec082.zip