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


I second Marty's sentiments, and will updated BP spec schema doc accordingly.

-karsten

>Re-sending due to a transmission error "relaying denied".
>
>*************************************************************************************
>
>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
>*************************************************************************************
>---------------------- Forwarded by Martin W Sachs/Watson/IBM on 04/20/2001
>10:44 PM ---------------------------
>
>Martin W Sachs
>04/19/2001 08:52 AM
>
>To:   tmcgrath@tedis.com.au
>cc:   Karsten Riemer <Karsten.Riemer@east.sun.com>,
>      ebxml-bp@lists.ebxml.org, ebxml-core@lists.ebxml.org, "'ebXML
>      Coordination'" <ebxml-coord@lists.ebxml.org> ebxml-tp
>From: Martin W Sachs/Watson/IBM@IBMUS
>Subject:  Re: BP specification and documents submitted to QR  (Document
>      link: Martin W. Sachs)
>
>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
>
>
>
>
>
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org




[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