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: Re: BP specification and documents submitted to QR


please see comments in  line...

Karsten Riemer wrote:

Tim,
A request for clarification on a couple of the QRT issues against BP
SpecSchema:

12      4/3     QRT     Line 369 and 536        “two” should be “more”. NB not confined to two
flows. (Is QRT pointing out an assumed errata, or is this a proposal for a
design change? A Business Transaction MUST in fact have either one or two
Document Flows associated with it, never zero, never more than two. Perhaps
the misuderstanding is that a BinaryCollaboration certainly can have more than
one (or two) business transactions, each with one or two docuement flows.
Unless there is something else behind this issue, I will flag it as "no change
required".)
 

it may have been our misunderstanding, we may have thought the model would enable a Business Transaction to involve many parties.

however, if your intention is as above, then may i suggest you make the following changes...

line 253 - add the statement "A Business Transaction must have either one or two
Document Flows associated with it, never zero, never more than two."

line 369 "Each Business Transaction shall consist of either one or two predefined Business Document Flows."

line 536 "A Business Transaction consists of a Requesting Business Activity, a Responding Business Activity, and either one or two Document Flows between them."

this does two things.  firstly, indicate that the term 'Business Transaction' is being used in its ebXML context.  secondly,  it emphasises that the cardinality is being explicit.  (unfortunately the phrase 'one or two' is often a throw away phrase for quantifying a group.)

 
27      4/3     QRT     Line 734-736    A CPA need not use an ebXML business process. ebXML
can be incrementally adopted.    28     4/3     QRT     Line 737        “must” should be “could”
(see point above).

Is the intent of these two issues to assert that an ebXML CPA need not refer
to any business-process-specfication at all, or that an ebXML CPA may refer to
some non ebXML business-process-specfication (or both)? I am corresponding
with TP team about this, but wanted to know the intent of the issue.
 

our intent is that "that an ebXML CPA may refer to some non ebXML business-process-specfication".

however, having made a quick check, i realise you are correct in your specification document.  

the current CPP/CPA spec states:
line 496 "The CollaborationRole element SHALL consist of the following child elements: a REQUIRED ProcessSpecification element, ..."

and subsequently...

line 554 "The ProcessSpecification element provides the link to the Process-Specification document that defines the interactions between the two Parties.  This document is prepared in accord with the ebXML Business Process Specification Schema specification[BPMSPEC]."

our concern is that this would prevent organisations not using business process models (in ebXML BPSS form) from using ebXML CPAs.  we cannot see why this restriction is necessary.

this is not a question for your team, we shall take this up with the TP team as well.

meanwhile, i suggest you keep the statement unchanged as it reflects the CPP/CPA specification.

 
thanks,
-karsten

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142
 



[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