RE: ebXML metamodel write-up

[Bob Haugen <linkage@interaccess.com>]

Karsten et al,

>I have written all of the above up in the attached document, and
>would like to request that this document become part of our next release of
>the BP specification and/or part of the architecture specification.

I like your document very much, but some details need work.
The Resources and Contracts package is not linked or used 
in the places it should be used, and one important use (templates 
or patterns) is not listed or explained.

_Links:_
1. Resources and Contracts are the stereotypes or abstractions
classifying BusinessInformation and Core Components.  So there
should be a described link between R&C & BI packages.
Scott Nieman recently discussed this usage in a comment
to Paul Levine following TMWG:
"Anything can be placed in a repository, however, there MUST be a
classification scheme to properly register "it", or you will never be able
to find it."  
The Resources & Contracts package should contain classifications
of the larger core components; Markets & Parties some more.  
One classification that we may need to add is Location; another
might be something like Quantification.  What's needed will
depend on the incoming core components, so new classifications
may be required as repositories evolve.

2. Also, Markets and Parties offer EconomicResourceTypes, so there
should be a described link between M&P and R&C.

_Templates or Patterns_ (I use Template, Jim Clark uses Patterns):
Re-usable configurations of classified objects can be provided
for many common situations that will greatly speed the design
of business process models.  For example, Jim Clark provided
a set of patterns for commercial transactions that were 
incorporated into the TMWG document.  The retail industry
GCI project had spent many days creating a model that would
have taken minutes had Jim's patterns been available to them.
Likewise, Bill McCarthy and I are working on templates for
both simple and contractual commercial exchanges.
Templates or patterns must be based on higher-level abstractions,
e.g. metamodels, and then instantiated with members of
concrete classes.  
The exchange templates will use stereotypes or abstract 
superclasses from the Resources and Contracts package.

Your "Use...Evolution" section should describe the use of
templates or patterns (and yes, we should decide on a 
common term) to define their B2B processes more
efficiently and correctly.  It is very common, and I saw
yet another demonstration last week, for experienced
business models to take days to model even simple
processes.  Templates or patterns can reduce this
time and confusion significantly.  

Design patterns have proven their value in the programming
arena; XML patterns are starting to take shape; commerce
patterns are next, and they are already starting to emerge 
from the TMWG and ebXML efforts.

Respectfully,
Bob Haugen