[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]
Powered by eList eXpress LLC