RE: Metamodel meeting 21 Nov.

[Tony Weida <TonyW@EDIFECS.COM>]

Karsten,

I share Jim's concerns about the terminology adopted in your email and
elsewhere, so in this note I'd like to specifically address those concerns.


First, I believe it's misleading, and therefore inappropriate, to tag the
already adopted metamodel with the epithet "methodology metamodel", since
the metamodel stands perfectly well on its own, completely independent of
any methodology.  To paraphrase one of your colleagues, if I give you a
model that is an instance of the metamodel, you can't tell me which
methodology, if any, was used to create it.  (I happen to believe that the
metamodel does lend itself rather nicely to a *complementary* modeling
methodology, but that's entirely beside the point here.)  Furthermore,
assuming that it's not helpful to rename exisiting things in ways that bias
our discussion, it is entirely appropriate to continue referring to the
already adopted metamodel simply as "the metamodel".      

Second, I believe it's misleading, and therefore inappropriate, to refer to
the proposal that you and others are advocating as THE "specification
metamodel", since it is neither more of an official ebXML specification than
the metamodel, nor should it be preferred over the metamodel when developing
specifications.

Thanks,
Tony

-----Original Message-----
From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
Sent: Monday, November 20, 2000 4:57 PM
To: Jim Clark
Cc: Karsten Riemer; ebxml-bp@lists.ebxml.org; ebxml-cc@lists.ebxml.org;
cory-c@dataaccess.com; alonjon@mega.com
Subject: Re: Metamodel meeting 21 Nov.


A response to Jim Clark's e-mail on this topic:

We are not defining a new metamodel, and I agree that the current metamodel
contains most if not all of what is needed. It just contains it in a way
that
is only with difficulty accessible for the layer that needs to drive the
actual software. It also is assuming a particular methodology is used. It
also
makes for a very complicated translation to XML.

The design objectives for the specification metamodel layer are:

1. Alignment between the methodology and specification metamodels, so that a

model against the methodology metamodel layers can be unambiguously
transformed to a subset of it against the specification metamodel layer.
2. Support for TP. Basically be able to replace all 'business' functionality
in  TPAml, i.e. the action menu.
3. Alignment with RosettaNet as per below.
4. Simplification for easier 'isomorphic' transformation to/from XML
5. Provide a simplified UML/XML layer against which you may create your
models
if you choose not to use the optional UMM methodology. 

We will proceed with the creation of a specification metamodel layer that
meets these objectives. That will be the topic of tomorrow's metamodel
meeting. We need input from anyone who has issues that need to be addressed
relative to each of the 5 objectives.

Jim Clark's use of the words "incorrect" and "disingenuous" is at this stage
subjective, so I will await further substantive and objective discussions
before I respond.

thanks,
-karsten

   


>Karsten et al,
>
>I object to the creation of a new meta model, the current metamodel and the
>semantics
>it defines are wholly suitable. Your defintion and description of the
>current
>metamodel is incorrect and disingenuous.
>
>This current direction will cause ebXML not to be interoperable with TMWG,
>RosettaNet, Swift and CGI.
>
>Jim Clark
>
>Karsten Riemer wrote:
>
>> The weekly BP/CC metamodel meeting is scheduled for 21 Nov. at
>> 9 am PST, 12 pm EST.
>>
>> To access the call, dial 888-699-0348 domestically and +1 732-336-6000
>> internationally, with  a PIN of 8154#.
>>
>> We will be continuing the work we started at Tokyo on creating a hand-off
>> layer between BP and TP. We now refer to that as the specification
>metamodel
>> as distinguished from the methodology metamodel. I attach the explanation
>of
>> the relationship between the two, as I submitted it to the TA team at
>Tokyo.
>>
>> The specification metamodel will be part of the March timeframe
>Infrastructure
>> Release, because it is needed in support of the TP specification, so we
>will
>> be working at an accellerated pace on this, including the metamodel/TP
>> face-to-face in Boston December 6-8.
>>
>> thanks,
>> -karsten
>>
>>
------------------------------------------------------------------------
>>                                           Name:
>MetamodelArchitectureChapter.doc
>>    MetamodelArchitectureChapter.doc       Type: WINWORD File
>(application/msword)
>>                                       Encoding: BASE64
>>                                    Description: Word.Document.8