[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Tomorrows meeting, and minutes from last meeting
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.
Powered by eList eXpress LLC