OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Comment on spec schema v.0.99


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC