Re: BP specification and documents submitted to QR

[Martin W Sachs <mwsachs@us.ibm.com>]

Regarding comment 27, lines 734-736:  This is mostly a TP team issue, not a
BP issue.  I agree that in principle, a CPP and CPA should be able to
reference a non-ebXML business collaboration description.  Hence, words to
the effect that a CPP or CPA MAY reference a description derived from the
BP Specification Schema might be appropriate in the BP Specification
Schema.

The reality of the situation is in two parts:

   1. The CPP and CPA have, in at least two places, elements and attributes
   that are specific to the BP Specification Schema.  It is highly likely
   that variants or completely different element structures would be needed
   in those areas to reference an alternative business collaboration
   description.

   2. The TP team has not done the work to either generalize the reference
   to the business collaboration description or to provide element sets for
   specific alternative business collaboration descriptions and it will not
   be possible to do this work before May 12, especially since the work
   might have to involve the organizations that "own" the alternative
   descriptions.  This work is most appropriately done in whatever venue
   takes over the CPP-CPA work after May 12. This joint work is the same
   model that the BP and TP team used to get as far as we have gotten.

The result of the above is that the CPA-CPP specification effectively
prescribes the use of the description derived from the ebXML BP
Specification Schema.  The TP team could add appropriate MAYs to its spec
but the reality of the situation is that alternatives are not supported at
this time because of (2) above.  The TP team could also add an informative
note suggesting allowing for alternative business collaboration
descriptions in the future but the last time this was discussed, the TP
team agreed that such a note is not appropriate in an approved
specification.  I would prefer simply to keep the subject on my futures
list.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Tim McGrath <tmcgrath@tedis.com.au> on 04/18/2001 10:02:08 PM

Please respond to tmcgrath@tedis.com.au

To:   Karsten Riemer <Karsten.Riemer@east.sun.com>
cc:   ebxml-bp@lists.ebxml.org, ebxml-core@lists.ebxml.org, "'ebXML
      Coordination'" <ebxml-coord@lists.ebxml.org>
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