[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: minutes from metamodel meeting
Forwarded from Karsten Riemer.
Paul Levine
BP PT Co-lead
---------------------- Forwarded by Paul R. Levine/Telcordia on 02/02/2001 05:28
PM ---------------------------
Karsten Riemer <kriemer@volcano.East.Sun.COM> on 01/31/2001 07:46:50 PM
Please respond to Karsten Riemer <kriemer@volcano.East.Sun.COM>
To: alonjon@mega.com, jjdubray@exceloncorp.com, cory-c@dataaccess.com,
plevine@telcordia.com, linkage@interaccess.com, jdc-icot@lcc.net,
mccarth4@msu.edu, kriemer@volcano.East.Sun.COM
cc: (bcc: Paul R. Levine/Telcordia)
Subject: minutes from metamodel meeting
Hi,
I still cannot send to ebXML lists,
Here are the minutes, and Haugen's mail re-attached. Paul, could you forward
it to the BP list.
Minutes from Metamodel meeting 1/30/2001
Attendees:
Bob Haugen
Bill McCarthy
Jim Clark
James Clark
Nita Sharma
Brian Hayes
Karsten Riemer
Agenda:
Status of SpecSchema v0.90
Discuss Haugen's proposal for addressing REA based pre/postconditions by
2/17/2001 Establish issues list for SpecSchema v.0.90
Establish issues list for Metamodel
Next meeting will be Tuesday 2/6/2000
Note NEW TIME: 11-12:30 EST
Assume same call info, or else we will send the new info out.
Discussion:
SpecSchema v0.90 has been approved for public review by QR, it is now in
executive review. By end of day Wednesday, if no issues raised by executives,
it will go out for public review.
We spent rest of meeting discussion Bob Haugen's proposal, attached in e-mail
format.
Our concencus was that work on REA based pre/postconditions needs to continue
on two fronts:
1. Business Process Editor team (Analysis team) will work through several
examples, and make sure BPE approach will be able to address REA based
pre/postconditions at least at Haugen's level two.
2. Metamodel team will
2.a. Put support for level one into current specification schema as part of
public review. This will require nothing more than a couple of new attributes.
This will enable BPE team to start working examples against level one. 2.b.
Work to support at least level two with an enhanced specification schema to be
submitted by February 17th.
In parallel we will evaluate additional multi party support for the
specification schema to be submitted by February 17th. BPE experimentations
will give us guidance here, too.
Received: from eastmail1.East.Sun.COM (eastmail1 [129.148.1.240]) by
volcano.East.Sun.COM (8.8.8+Sun/8.8.8) with ESMTP id IAA21279 for
<kriemer@volcano.East.Sun.COM>; Tue, 30 Jan 2001 08:50:49 -0500 (EST)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by
eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25833;
Tue, 30 Jan 2001 08:50:50 -0500 (EST)
Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by
patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20405; Tue, 30 Jan 2001
05:50:49 -0800 (PST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856)
id <0G7Z00C01AB1YP@eListX.com>; Tue, 30 Jan 2001 08:47:32 -0500 (EST)
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id
<0G7Z00C04AB0YK@eListX.com> (original mail from linkage@interaccess.com) ; Tue,
30 Jan 2001 08:47:24 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856)
id <0G7Z00C01AAZYI@eListX.com> for ebxml-bp@elist.lists.ebxml.org (ORCPT
ebXML-BP@lists.ebxml.org); Tue, 30 Jan 2001 08:47:23 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856)
id <0G7Z00C01AAZYF@eListX.com>; Tue, 30 Jan 2001 08:47:23 -0500 (EST)
Received: from mcfeely.interaccess.com (from.interaccess.com [207.208.131.20])
by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G7Z00A9RAAXB4@eListX.com>;
Tue, 30 Jan 2001 08:47:22 -0500 (EST)
Received: from dsl-64-128-16-229.telocity.com (d130.focal6.interaccess.com
[207.208.186.130]) by mcfeely.interaccess.com (8.10.2/8.10.2) with SMTP id
f0UDkUt24208; Tue, 30 Jan 2001 07:46:30 -0600 (CST)
Received: by dsl-64-128-16-229.telocity.com with Microsoft Mail id
<01C08A90.C292D3E0@dsl-64-128-16-229.telocity.com>; Tue, 30 Jan 2001 07:46:31
-0600
Date: Tue, 30 Jan 2001 07:46:22 -0600
From: Bob Haugen <linkage@interaccess.com>
Subject: Order-Fulfillment-Settlement patterns
To: "'ebXML-BP@llists.ebxml.org'" <ebxml-bp@lists.ebxml.org>,
"'ebXML-CCBP-Analysis (E-mail)'" <ebxml-ccbp-analysis@lists.ebxml.org>
Message-id: <01C08A90.C292D3E0@dsl-64-128-16-229.telocity.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
List-Owner: <mailto:ebxml-bp-help@lists.ebxml.org>
List-Post: <mailto:ebxml-bp@lists.ebxml.org>
List-Subscribe: <mailto:ebxml-bp-request@lists.ebxml.org?body=subscribe>
List-Unsubscribe: <mailto:ebxml-bp-request@lists.ebxml.org?body=unsubscribe>
List-Archive: <http://lists.ebxml.org/archives/ebxml-bp>
List-Help: <http://lists.ebxml.org/doc/email-manage.html>, <
mailto:ebxml-bp-request@lists.ebxml.org?body=help>
Content-Length: 6962
I am sending this to the BP list for Tuesday's Specification Schema
conference call, and also to the BP-CC-Analysis list for that group's
Wednesday conference call.
I think members of both groups need to be involved in this problem,
which is how to provide enough support for business collaboration
patterns in ebXML version 1.0 (spec due to QR by Feb 17) that 1.0
will be credible for modeling some simple real world cases.
**** Table of contents:
- Ambitiousness of implementation
- Expression scope
- Document references
- Responsibilities of work groups
*** Ambitiousness of implementation
There are several possible levels of ambition, from simplest
to more elaborate and probably more useful. The levels of
ambition build on each other.
1. Simplest: permit arbitrary strings in pre and post conditions,
and have the software keep track of them as something like
"facts" or "assertions", along with the documents they apply to
(see below under Documents). By "assertions", I mean in the
sense of knowledge bases, not programming. Postcondition
expressions assert facts, precondition expressions can check them.
Business Process Editors could validate precondition expressions
to see if they were established by a postcondition. We could
suggest assertion guidelines, but they would really be free-form.
Some REA collaboration patterns could be expressed
in this limited way, but it will be difficult to demonstrate
recognition of accounting and legal events.
In addition, the expressions could become catch-alls for
kludges of all kinds. In other words, I do not recommend
this level of ambition, but it may be the simplest thing
that could possibly work.
2. Simple recognition of economic commitments and events,
with a controlled vocabulary:
We establish a vocabulary, based on the Economic Elements
in the metamodel BRV with maybe some subtypes like
"Order", "Product", "Delivery", "Payment", etc.
I think that a sufficiently inclusive list of these elements
can be lifted from the REA ontology and core components,
so this should not slow down our process.
The only facts that can be asserted in postcondition expressions
or checked in precondition expressions are those that use
this vocabulary (in addition to expressions already permitted
under other rules, e.g. success or failure of previous transaction).
The vocabulary could be constrained programmatically, such as
in Business Process Editors.
3. Keep track of states of economic commitments and events:
In addition to asserting that an Order exists, for example,
postconditions could assert that the Order is in a particular
State, e.g. Proposed, Accepted, Fulfilled, Settled (or Completed),
etc. Same for other economic elements. This would
require the software to keep track of more-than-strings,
that is, to keep track of entities and update their states.
"State" could be just a string, or it could be part of a
state graph. State strings could be arbitrary, or constrained
by lists that are part of some reference model.
States would support contract/order negotiation as well
as economic event disputes. Keeping track of entities
might require identities (e.g. more than one Order in a
collaboration), or we could just support one of each
type of economic element in an expression scope.
(See Expression Scope below.)
This and the next ambition level essentially require
the creation of runtime objects with properties.
4. Allow expressions based on properties of economic
elements, like quantity and dateAndTime. This was
my original proposal for supporting business collaboration
patterns. It is probably too much to do by Feb 17.
Expressions based on document contents could be done
with any of these complexity levels, as long as the software
layer was able to open the document envelope.
This level of ambition might require more metamodel changes
than the others.
***Expression scope
I think it would be best to specify the scope of an assertion
to be the scope of the surrounding collaboration activity
graph, e.g. the current transaction for transaction assertions,
and the current collaboration for collaboration assertions.
So if you wanted an assertion to be usable in a collaboration
scope, you would need to publish it as a postcondition of
an included collaboration or transaction.
A related issue: do we support different instances of the
same expression in the same scope? If so, they need to
be identified and differentiated, possibly by Document
Envelope reference (if those are differentiated).
***Document references
What is passed to the enclosing layer of software:
Both the postcondition assertion as well as a reference to the
document envelope(s) that it applies to. This could get a little
kinky, because e.g. for an Order, you might want to get both
the Requesting document envelope and the Responding
document envelope, especially if you are supporting
order states like counter-offers. (Question to business
requirements group: when would bindings to multiple document
envelopes be necessary?)
I am assuming here that assertions are initially expressed
as postconditions of business transactions, so the requesting
and responding document envelopes are known. (That could
also be a way of differentiating assertions with the same
expression.) Collaborations of many transactions should be
able to raise the same assertions to their enclosing software
layer, including the same document envelopes.
Any of the above ambition levels seem to me to require
references from asserted facts (or created economic
elements) to document envelopes.
*** Responsibilities of work groups
I propose that the Analysis and Methodology group be responsible
for the business requirements and Business Process Editor changes,
and the "Metamodel" group be responsible for changes to the
Specification Schema to support the business requirements.
Actually, depending on the ambitiousness of implementation, the
UMM metamodel may already include almost everything required
to support collaboration patterns, except for some minor
refinements (which may just be documentation improvements):
* how to express economic elements in post and preconditions;
* how economic elements are related to CommercialTransactions;
* the scope of post and precondition expressions;
* the connection of postcondition of expressions to DocumentEnvelopes.
I also very strongly urge the preservation of the UMM metamodel as
a reference model for both Specification Schema and Business
Process Editor. In other words, the mechanisms for supporting
business collaboration patterns should be the same or at least
strictly derivable from metamodel to specification schema and BPE.
Respectfully,
Bob Haugen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC