Summary of Wednesday conference call

[Bob Haugen <linkage@interaccess.com>]

As those of you who attended know, I was deputized by the
Boston metamodel face-to-face meeting to get feedback from
the Common Business Process work group on the "specification
schema" developed in Boston.

If you attended the call, please send additions and corrections
in reply to this message.  If you did not attend, and have comments
on the Boston results (posted to the main BP list), please send
them directly to the BP list.

I will post a revised version of this message to the BP list tomorrow.

Attending the conference call were:
Bob Haugen
Brian Hayes
David Welsh
Jim Clark
Jenny Xu
(please tell me if I missed anybody)

I will not attribute most comments to particular individuals,
but as a consensus list of issues and comments.  Again, 
please tell me if you think there was no consensus on a particular topic.

1. Comments on the diagrams in the file ebXmlSpecificationModel08.pdf
included in the zip archive in the message:
http://lists.ebxml.org/archives/ebxml-bp/200012/msg00029.html

In the diagram on page 1, the classes Package and Package Content
do not appear in the metamodel nor in any of the other submissions
from the Boston meeting, nor do they make sense in terms of a
business collaboration.

Likewise, the diagram on page 2 appears to be a deviation from the
metamodel and the other diagrams from Boston.

2. In general, names should be the same from the metamodel to
the specification schema to the DTD (where the names refer to
the same concept).  

3. Can the same document type be used for both success and failure?
    There was a long discussion here which repeated those in Boston
    about the different termination states of a business transaction -
    Success, Control Failure and Business Failure - and the various
    causes of each.  One answer to the above question was that
    if (for example) a Purchase Order Reponse document type was
    returned in response to a Purchase Order Request, and the
    Response document said it rejected the Purchase Order Request,
    the business transaction could still end in success, and the
    fact that the order was rejected would need to be handled in
    higher-level collaboration software.  (I do not think this is an
    adequate summary of a long discussion, but it would take
    a whole document about business transaction and collaboration
    design considerations to do much better.  Suggestions 
    would be welcome here...)

4. The name Document Transition Vehicle was disliked; the group liked
    the original Document Envelope better.  There was a long discussion
    over whether double-wrapping of documents was necessary (business
    Document Envelope in addition to transport packaging).  At the end,
    double-wrapping seemed to be justified for process-to-process 
    security and multiple documents in one Envelope.

5. A related question: is Document Envelope required?
    Answer: yes for Requesting Activities and substantive responses,
    no for business signals like acknowledgments.

6. Does RosettaNet use Document Envelopes?  Jim Clark says
    there is a similar structure with a different name.  He will research
    what the exact name is and if there are any significant differences.

7. An unanswered question:  will transferring from one e-commerce
    framework to another be trouble?  For example, X12 or BizTalk
    or Commerce One or RosettaNet to ebXML.  Jim Clark says
    that RosettaNet to ebXML will be no trouble; the others will
    require translators (at least).  

8. All views of the metamodel should be able to be registered
    and retrieved from registries, not just the elements in the
    specification schema.  The BRV and BOM views will be useful
    for process documentation, analysis and queries.  Tracking and monitoring
    software may be developed using higher-level views of collaborations,
    if nothing else.  

9. Being able to monitor the current state of a transaction or collaboration
    will be critical to successful electronic business.

10. The infrastructure release with a limited specification schema
      should not be regarded as the end of the road for ebXML; there
      is a lot more to do - in particular, higher levels of collaboration
      such as order, fulfillment and payment.
      How is the infrastructure release going to be different from
      traditional EDI?  What the added business value?
      There was general concern that the infrastructure release
      was no more capable than RosettaNet.  A quote from
      David Welsh:  "ebXML is about doing business, it's not
      about transport."

11. Can other methodologies be accomodated besides UMM -
      in particular, IDEF?  The consensus was that IDEF diagrams
      could be derived from UMM models, but not round trips.
      The metamodel was too dependent on UML semantics
      to be completely specified in IDEF.

12. A related question:  has UMM been adopted by ebXML or not?
     (The significance here is that the Common Business Process
     and Methodology subgroups have adopted UMM as their 
     methodology.)  Jim Clark said that the BP metamodel uses
     UMM, and that UMM has embraced the BP metamodel, but
     the answer to the above question is not clear.

Please send feedback.
Respectfully,
Bob Haugen