spec schema sample for POC + issues

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

As discussed in yesterday's BP/CC I have created a draft of a spec schema
sample for the "DropShip" business process that is being proposed for the POC.
The POC meeting is happening today, so it is likely that the flow or content
will change. 
This e-mail is more to describe issues/questions I came across while writing
the .xml

I started with the attached (dropship7) document from the analysis group, and
mapped as closely as I could to the table specifying the binary
collaborations, transactions, and roles. The result is attached
dropshipSamples.xml. (For POC the current thinking is to skip the "Ship Goods"
collaboration so I didn't do that one)

Here are the issues/questions I came across:

1.  Four out of the six binary collaborations are single transaction. Under
spec schema v0.99 I have to create a separate binary collaboration for each
transaction. There are duplicated attributes at the BinaryCollaboration and
BusinessTransaction levels, and it is unclear for a single transaction
collaboration which level is most relevant to use (beginsWhen, endsWhen,
requires, resultsIn)

2.  The Product Fulfillment binary collaboration expects to use different role
names for each of its two transactions. Under spec schema v0.99 role names
must be the same for all transactions within a binary collaboration.

3.  The Inventory Management binary collaboration contains two alternative
ways of obtaining an inventory report, one by request, and one unsolicited. In
either case the content and structure of the report document(s) is the same.
Under spec schema v0.99 I have to define separate BusinessTransactions for the
two alternate ways, each with its own unique DocumentFlow. (This is the same
issue as issue # 116 by William Kammerer)

4.  As per 1. above, you cannot under v0.99 create a CPP or CPA that declares
support for a single transaction, or a single document flow, unless you create
a binary collaboration containing that transaction.

These three issues would be addressed if we adopted my proposal as per issue
#124, and it would also make us more compatible with current RosettaNet
thinking and upcoming OMG/EDOC specification. I attach my original e-mail with
that proposal.

thanks,
-karsten

Word.Document.8

MozillaXML

---

• From: Karsten.Riemer@east.sun.com
• To: ebxml-bp@lists.ebxml.org
• Date: Wed, 28 Mar 2001 00:54:05 -0700 (MST)

Proposal for SpecSchema 1.0

Inspired by Jamie Clark’s suggestion to look for a solution that preserves the current UMM mapping but achieve a better mapping to EDOC and future RosettaNet thinking I am making the following suggestion, which has several additional benefits listed below.

Consider this a set of formal comments to spec schema v0.99 when the public review period closes (I am in Africa and may not be able to connect again).

1.	BusinessTransaction to inherit from BinaryCoillaboration giving it two AuthorizingRoles and allowing definition and implementationof  a standalone BusinessTransaction
2.	DocumentFlow to to inherit from BinaryCoillaboration giving it two AuthorizingRoles and allowing definition and implementationof  a standalone DocumentFlow, i.e. support for a single message, in addition to the transaction support
3.	BusinessTransaction to have N DocumentFlowActivities each using a DocumentFlow. This would in essence be a renaming of Requesting/RespondignBusinessActivity, and a relaxation that there must be only two of them.

Functionality gained from the above:

Can define and implement a single transaction, or a single message without having to define a separate binary collaboration.

Have Roles for CCP to map to at all levels.

Have transaction parameters in DocumentFlowActivity where both parties can see them.

Have recursive role decomposition from MultiParty to Binary to Transaction to DocumentFlow, i.e. the top to bottom recursiveness that the RosettaNet architects were looking for. Initiatior/Responder can be flip-flopped at any level and within any level.
Each collaboration level has an initiator and a responder, each of which can initiate or respond in an activity pointing to the next level down collaboration.

Model supports notification (single DocumentFlow), Request/Response (use of two DocumentFlows) and is ready for more complex transaction patterns (three or more DocumentFlows).

I would like interested parties to think about this and we can then decide whether the comments raised during public review warrant these additional changes.

thanks,
-karsten


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

---