Subject: RE: There already is a separate Meta model!
Mark, I trust that you understand from my previous posting that Cory misspoke when he referred to "the TP is already using another Meta model". He was presumably looking at the IBM proposal and not at any output from the TP team. Indeed, the TP team is so new that it is only beginning to define its specification. I believe that the TP team's function is to provide a need for e-business that none of the other teams are meeting. That's why a new team was set up for profiles and agreements. We are not trying to define functionality for other areas. We are working with the other areas to define the appropriate intersection points. As to approved TP requirements, I provided the requested requirements text to the Requirements team when we were in Tokyo. I provided it again the next day when the diskette had apparently been lost the previous day. I expect that the Requirements team will contact me if there is any problem with what I submitted. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Cory Casanave <cory-c@dataaccess.com> on 11/21/2000 02:49:51 PM To: "CRAWFORD, Mark" <MCRAWFORD@lmi.org>, Cory Casanave <cory-c@dataaccess.com>, Karsten Riemer - Sun IR Development <Karsten.Riemer@east.sun.com>, jamesc@edifecs.com cc: linkage@interaccess.com, ebxml-bp@lists.ebxml.org, ebxml-cc@lists.ebxml.org, alonjon@mega.com Subject: RE: There already is a separate Meta model! 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:MCRAWFORD@lmi.org] > Sent: Tuesday, November 21, 2000 2:37 PM > To: 'Cory Casanave'; Karsten Riemer - Sun IR Development; > jamesc@edifecs.com > Cc: linkage@interaccess.com; ebxml-bp@lists.ebxml.org; > ebxml-cc@lists.ebxml.org; alonjon@mega.com > 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:cory-c@dataaccess.com>] > Sent: Tuesday, November 21, 2000 2:24 PM > To: Karsten Riemer - Sun IR Development; jamesc@edifecs.com > Cc: linkage@interaccess.com; ebxml-bp@lists.ebxml.org; > ebxml-cc@lists.ebxml.org; cory-c@dataaccess.com; alonjon@mega.com > 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 >
Powered by
eList eXpress LLC