Mark,
The TP team is not encroaching they are proceeding. They have been very
open to receive a suitable model from BP, my point is that if we fail to
provide one they will proceed with a solution - and they should. The
solution we provide must also fit with the TP requirements for what is
practical to drive such an execution layer - we can not be ignorant of
implementation reality or the timeframe practicality of integrating such a
model.
Cory
> -----Original Message-----
> From: CRAWFORD, Mark [SMTP:[email protected]]
> Sent: Tuesday, November 21, 2000 2:37 PM
> To: 'Cory Casanave'; Karsten Riemer - Sun IR Development;
> [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: RE: There already is a separate Meta model!
>
> Cory,
> You imply the TP meta model is an approved approach. I would
> submit to you the TP group does not have an approved set of requirements,
> much less an approved specification with a separate metamodel. I would
> also submit to you that TP's function is to support the needs of the other
> ebXML project teams and if they are trying to define specific
> functionality within other areas, IMHO they are out of scope.
>
> It is important to note the only approved ebXML technical
> specification at the moment is the requirements document. Section 3.3 of
> that document clearly delineates metamodel definition responsibility to
> the business process group.
>
> If BP feels that TP is in fact encroaching, then the BP lead
> should raise this issue to the Steering Committee.
>
> Mark Crawford
> Requirements Team Editor
>
> -----Original Message-----
> From: Cory Casanave [ <mailto:[email protected]>]
> Sent: Tuesday, November 21, 2000 2:24 PM
> To: Karsten Riemer - Sun IR Development; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: There already is a separate Meta model!
>
>
> I have been watching all the dialog about the need for a specification
> Meta
> model and it's degree of alignment with the collaboration model. It seems
>
> we are missing an important point - the TP is already using another Meta
> model, one not derived or aligned with the collaboration model at all.
> This
> model is used to drive the execution engine of the TP layer.
>
> I have strong doubts that the collaboration model will ever be used to
> drive
> the execution engine. What we are in danger of, by our continued
> thrashing,
> is that there will be NO relation between the execution model and business
>
> modeling. It will be a BIG WIN for EbXml to be able to show business
> modeling (which is how I think of the collaboration + REA model) with a
> firm
> mapping down to such an execution model - lets not loose this advantage
> with
> religious wars.
>
> Unless we get our act together the current (TPA) execution model will go
> forward as part of the first EbXml release and will be very hard to
> unroot.
> We will be forced to adapt the business semantics to meet the capabilities
>
> of the implementation rather than the other way around.
>
> So, the assertion is that we WILL HAVE an intermediate model, one way or
> another.
>
> That it would be far better to cooperate to make this integrate with
> business modeling and the execution model.
>
> Discussions of "it is or is not the same model" are useless.
>
> You have at-most a month, after that the technology implementation will
> have
> gone to far.
>
> Karstens model is the only base line to proceed from. If there are
> missing
> semantics, work it out.
>
> If we succeed we will be able to keep a traceable path from business
> modeling to execution & compatibility with RosettaNet, CGI,
> TMForum, UN/EDFACT, ect
>
>
> Regards,
> Cory Casanave
>
