ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC