Re: ebXML metamodel write-up

[srh@us.ibm.com]

Please excuse a temporary total disregard (but not disrespect)
for what is in the requirement doc on this,
but something bothers me about this; somehow it seems we would
have an excellent team, and have done alot of work to move the
ball to 90 yard line and then sort of walk away.......Hmmmmm

Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Karsten Riemer - Sun IR Development <Karsten.Riemer@East.Sun.COM> on
07/25/2000 04:42:10 PM

Please respond to Karsten Riemer - Sun IR Development
      <Karsten.Riemer@East.Sun.COM>

To:   ebxml-BP@lists.ebxml.org
cc:   duane@xmlglobal.com
Subject:  Re: ebXML metamodel write-up



FYI,
my metamodel write-up has circulated on the architecture list and
has drawn the comments included below.
Does anyone on the BP team have a reference in the requirements
doc to the need for discovery of products and services within a
market place? If not, maybe Duane is right, we should drop it.
That would not preclude the discovery of particular kinds of processes.
I think what Duane is suggesting is that we keep the process category
kind of discovery, but drop the marketplace kind of discovery.
Marketplace would still remain in the model as one of the ways to
derive context.

-karsten


------------- Begin Forwarded Message -------------

Date: Tue, 25 Jul 2000 12:41:47 -0700
From: Duane Nickull <duane@xmlglobal.com>
MIME-Version: 1.0
To: Karsten Riemer - Sun IR Development <Karsten.Riemer@east.sun.com>
CC: ebXML-Architecture List <ebxml-architecture@lists.ebxml.org>
Subject: Re: ebXML metamodel write-up
Content-Transfer-Encoding: 7bit

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

------------- End Forwarded Message -------------


---------------------------------------------------
Karsten Riemer,
Director, Information Architecture,
Enterprise Management Architecture Group
Sun Microsystems Inc.,
MailStop UBUR03-313
1 Network Drive,
Burlington, MA 01803-0903

ph. 781-442-2679
fax 781-442-1599
e-mail karsten.riemer@sun.com