Tomorrows meeting, and minutes from last meeting

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

The weekly BP/CC metamodel meeting is scheduled for 17 Oct. 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 4281#.

Agenda:
Work on XML level expression of BP and info models.

See you there,

Karsten



Minutes from Metamodel meeting 10/10/2000

Agenda:

Review of XMI documents.
Attempt to settle on XML format for POC.
Discussion of BP elements needed for TP.
Discussion of Partner definition.
Scheduling of FSV review.
Process for review of metamodel.

Attendees:

Bill McCarthy
Bob Haugen
Core Casanave
Mike Rowell
Jean-Jacques Dubrais
Anne Hendry
Antoine Lonjon
Paul Levine
Stefano Pogliani
Tim McGrath
Karsten Riemer
Sig Handelman
Scott Hinkelman
Mark Hale
Chris Ferris
Marcia McClure
Martin Bryan

Review of XMI:

Scott mentioned that Kris Ketels from Swift is addressing use of XMI under TA.
Antoine will contact Kris.

Mark Hale mentioned RDF as an alternative, referred to e-mail by Bob Miller.

Sig Handelman mentioned that he thought XMI might be too complex as the XML
dialect for the final XML expression of a BP/Info model (referred to in the
rest of these notes as simply BPI-XML, this is not a new term, just ane easy
abbreviation for these notes). Scott stated that we should work on a set of
minimum but sufficient requirements for this BPI-XML.

Chris Ferris mentioned that there are two flavors of XMI, both MOF compliant,
one for model interchange, one for domain specific models. Chis also mentioned
that one goal would be to have a simple instance level document like the one
demoed in Bruxelles.

There was discussion about whether the BPI-XML should support any kind of
userfriendly display directly, or whether implementors would provide their own
transforms. Concencus seemed to lean towards the latter.

Scott mentioned that Steve Brodsky of IBM is involved in the use of XMI for
'movement of objects', whereas ebXML is mostly about interoperability in
exchanging business documents.

Editorial: Summing up the discussion we might have an architecture something
like this:

UML-modeling tool              XML-modeling tool            XML-browser tool
       |                               |                           |
      XMI                              |                           |
       |_______________________________|___________________________|
                                       |
                                    BPI-XML

The left branch fully supporting the recommended ebXML methodology, the middle
branch being lighter-weight but fully semantically compliant with the left
branch.

Cory Casanave mentioned that if we were basing the architecture on MOF
directly we would more easily be able to create the simplified BPI-XML, and
transformations via XSLT to graphical tools would be more straight forward.
Editorial: this is not the direction of the ebXML metamodel, we are focusing
on an extension to current UML.

Scott mentioned that he thought that the BP group is focusing on methodology
and that it is becoming too heavyweight. Bob Haugen agreed in spirit, and
stated that he thought there was much room for simplification within the
current BP specs without starting over.

Eveyone in the meeting agreed that the right approach for the metamodel team
right now is to  concentrate at the BPI-XML layer, and then work from that
middle-out, i.e. to tie it to the upper BP model and to the TP models below
it. Chis Ferris stated agreement but again recommended that we use the XMI
domain specific XMI as a starting point.

Lisa Shreve stated that the methodology's focus on starting at the
requirements level is not the right choice. We should instead establish design
rules. The metamodel must be the active foundation which 'nudges' users in the
direction of correct construction of data structures.

Scott stated that we need b2b specific tools, message oriented.
Cory stated that ideally "the model is the source code".

Bob stated that there is a need for more specification of the new kind of
software that "knows how to be configured by TradingPartner config files"

Martin Bryan that focus should be on discovery of processes first, then
players. This is different than focus on what you do when you already have
agreed upon an interaction with a known business partner.

Scott stated that in essence TPAml is the M-zero level underneath the BPI-XML
M-one level. i.e. the BPI-XML is the generic statement of the process. The
TPAml is first a statement of a partner's capabilities with respect to that
generic process, next a statement of two partner's explicit commitment to use
those capabilities in a specific way.

Bob Haugen wanted to know the mapping of TP to BP. Editorial: this is the
topic of TP face-to-face in New York.

Editorial: This meeting covered a lot of good ground, and brought out clear
concensus that we should concentrate on the BPI-XML layer. This will be the
agenda for tomorrow's meeting.