Re: ebXML metamodel write-up

[Duane Nickull <duane@xmlglobal.com>]

Thanks Karsten:

Here are some comments:   


Your meta model states:

>>>Steps of electronic business
In order for enterprises to "do business with each other" they must
first:
1.	Find out about each other's existence and what products and services
they can offer each other<<<

IMHO - this is explicitly out of scope of ebXML.  The discovery phase
has not been adressed in the TA Spec nor have they been included in any
discussions.  I did not recall it being included in the Requirements
Document which mandated our Technical Architecture Specification.  If
this is wrong, someone please correct us now.

On Page 2, it states:
>>>>>The ebXML metamodel consists of distinct but interrelated sub-metamodels each corresponding to one of the 6 steps of doing electronic business as described above.
1.	Markets and Parties: For describing and discovering the markets, the
market players and their product and service offerings<<<

I totally agree with the subsequent discovery of process uses for ebXML
however, I did not recall the actual marketplace for discovery as being
within the scope fo ebXML and our group, Technical Architecture, has not
completed any work in this realm.  We anticipated that existing
electronic marketplaces would facilitate this goal and ebXML will
concern itself with the remaining 5 items on your list.

Please - again someone correct us if we are wrong here.  We specifically
are mandated by the Requirements document which does not describe any
such functionality (to my knowledge).

On page 3 you wrote:

>>>Independence of ebXML sub-metamodels

Although clearly interrelated, the ebXML sub-metamodels are not tightly
dependent on each other, and implementations of one can be very
beneficial even in the absence of implementations of one or more of the
others. <<<

This is totally not true in the case of business process and business
information.  The business process is dependent on being able to specify
which core components (data Elements) are necessary for each party to a
transaction to meet their respective legal and business requirements. 
One cannot exist effectively without the other.  I can't just say "send
some information to me" to place a Purchase Order.  It has to be
specified "Please send me the thing I call address, the thing I call
name, the thing I call telephone number etc.  Each of those objects has
to also have the ability to be referenced via a repository so the sender
also knows what they are.  The semantic reference from a repository
dictates that the RegRep access process be integrally bound to
potentially all transactions (at least in an abstract way - we are
suggesting the use of a cache in the application to ease congestion to
the repository query daemon).

Also - A core component cannot be used effectively without a contextual
guide to allow it to be instantiated correctly depending on the business
process it is part of.  I can't just say Item <a> is equivalent to Item
<b> if there are ten places in each document where there are instances
of those elements.  I need to know the context in which thety are being
used.

TRP as a stand alone - yes - excellent work being done there.  

I look forward to seeing more on the subject of using the UML -> XML
process for data elements and business processes.  This is an area we
are concerned about.

Duane Nickull