RE: Feedback from Common Business Process Group on Boston schema

[LONJON Antoine <ALonjon@MEGA.com>]

I think that the package element corresponds to "BusinessCategory" (see
attached file) in the metamodel, which inherit from Package.



-----Original Message-----
From: Cory Casanave [mailto:cory-c@dataaccess.com]
Sent: lundi 18 décembre 2000 18:10
To: Bob Haugen; 'ebxml-ccbp-analysis@lists.ebxml.org';
'ebXML-BP@llists.ebxml.org'
Subject: RE: Feedback from Common Business Process Group on Boston
schema


In Reference to: 
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 did they make sense to the group 
    in the context of a business collaboration.

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

Since I put these in I will note their origin (which is also noted in the
change logs).  At the meeting we concentrated on the central and most
important elements, like sequencing semantics.  We spent zero time on
"supporting" elements like definition of name spaces (the context in which a
business collaboration is defined) or how attributes would be applied.
These were presented & discussed by example several times without
controversy.  In doing the work to make the schema, example and DTD
consistent these detail items had to be taken care of.  I used the example
and the prior version of the schema as a base to make sure the schema could
hold all of the detail items required & already used in the example - they
will have to be someplace.  Since XML is the way the process spec will be
transferred & stored we must be formal about it's contents and semantics.

Regards,
Cory Casanave

> -----Original Message-----
> From:	Bob Haugen [SMTP:linkage@interaccess.com]
> Sent:	Friday, December 15, 2000 3:25 PM
> To:	'ebxml-ccbp-analysis@lists.ebxml.org'; 'ebXML-BP@llists.ebxml.org'
> Subject:	Feedback from Common Business Process Group on Boston schema
> 
> 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. Here is my
> report.
> 
> I got most of the comments on the Wednesday CCBP-Analysis
> conference call.
> 
> Attending the conference call were:
> Bob Haugen
> Brian Hayes
> David Welsh
> Jim Clark
> Jenny Xu
> 
> Further comments after the conference call came from
> Mary Kay Blantz and Jim Clark.
> 
> I will not attribute most comments to particular individuals,
> but as a consensus list of issues and comments. (It was
> a lively discussion.) Some people will be named where I thought 
> it would help to clarify the meaning, or followup might be needed,
> or it was not clear that this was a consensus statement.  David
> Welsh's slogan below was definitely consensus, I just wanted
> to give credit where due.
> 
> 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 did they make sense to the group 
>     in the context of a business collaboration.
> 
>     Likewise, the diagram on page 2 appeared 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).  (This was a consensus policy agreement, 
>     not specifically directed at anything in the Boston documents.)
> 
> 3. 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.  I tried to summarize this discussion, but concluded
>     that the best summary was the suggestion during the meeting to
>     provide a "Primer" to explain all of this stuff.
> 
> 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.  
>     Mary Kay Blantz: "Our vision is that companies/industries who wish to 
>     standardize their implementations would be able to find their business
> processes 
>     in the repository.  We will recommend that they develop models and
> essentially
>     'match' the models.  I don't see how this can be done if they are not
>     using the same methodology." (This comment applies to this issue,
>     storing all views of a business process in the repository, as well as
>     to the issue of a standard methodology.)
> 
> 9. Being able to monitor the current state of a transaction or
> collaboration
>     will be critical to successful electronic business. (I interpret this
> as
>     a requirement for ebXML collaboration software to keep track of
>     the state of the collaboration.)
> 
> 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.  
> 
> 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.)  
> 
>      Mary Kay Blantz: "I thought that UML (and therefore UMM) was chosen.
> 
>      Seems very late in the game to consider alternatives."
> 
>      Jim Clark: "The UMM is supported by, has incorporated the metamodel. 
>      Not the other way around.
> 
>      "The way to think about it is as follows.
>      1) The metamodel precisely defines the syntax and semantics of a
> business domain.
>      2) The patterns constrains the use of the semantics into well
> structured
>          artifacts of common use.
>     3) The UMM prescriptively defines a set of steps to follow to assure
> that
>         processes defined using the patterns are complete and well formed.
> 
>      "The UMM is based on or uses a set of patterns that are based on or
> defined by 
>      a set of semantics (metamodel).  The metamodel does not require the
> use of a
>      certain methodology, however the UMM has been developed to
> efficiently answer the
>      questions and define the requirements that occur in eComm domain."
> 
> Respectfully,
> Bob Haugen
> 
> "ebXML is about doing business, it's not about transport."
> -David Welsh
> 
> P.S. further comments and corrections should be directed (at least)
> to the BP list.

package.gif