RE: Metamodel meeting 21 Nov.

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

I am very open to any suggestion for names. I just needed labels so I could
show how they related to each other. 4-layer-cake and 1-layer-cake would work,
too. Or Full-ebXML and Infrastructure-ebXML. 

-karsten

>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
>