ebxml-tp message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: TP teleconference minutes - Feb. 28, 2001


I am sorry I did not attend the conf call and, thus, did not comment on this
during it.
I disagree on the sentence :

 2. Multi-party collaborations can always be reduced to sets of binary
 collaborations, each with a separate CPA

I agree that, for V1, we assume that this is possible. But I do not think
that this would account any general situation.

/stefano


 -----Original Message-----
 From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
 Sent: 01 March 2001 17:32
 To: ebxml-tp@lists.ebxml.org
 Subject: TP teleconference minutes - Feb. 28, 2001


 Here are Tony Weida's minutes of the Feb. 28 conference call, with a few
 minor additions by me.

 Regards,
 Marty


 Attendees:

 Jamie Clark
 Dale Moberg
 Becky Reed
 Marty Sachs
 Tony Weida


 Becky is working on the new FTP definition to be finalized by
 Friday night.

 Dale noted that the Security team has a teleconference going on
 at the same
 time as our call.

 Marty reminded us of concerns he has about send capabilities (for details
 of
 this and other items, see his Feb. 26 listserv posting on "CPA-CPP ver.
 0.92
 distributed today").  First, send properties are tied to specific receive
 protocols.  According to Marty, Chris thought that was okay.  Also,
 SendingProtocol is a child of Transport.  Dale responded that he put it
 there to aid CPA negotiation based on CPPs. We decided to leave the send
 capabilities as is.

 Dale agreed with Marty that the cardinality for SendingProtocol
 in a CPA is
 exactly one.

 Tony accepted an action item to contact Chris and settle with him on the
 mechanism for validating references to process specifications.
 One specific
 issue is whether there should be separate digests of the
 Process-Specification
 Documents or whether they should be included within the overall signature
 of the CPP or CPA.

 Marty raise the question of whether a Packaging element is needed under
 Override elements and reported that Chris thought it unnecessary, that
 overrides should have packaging requirements in common with their
 ServiceBinding.

 Marty pointed out that the DTD specifies the cardinality of the Packaging
 element as one or more, but the text of our spec says exactly one.
 Conclusion: TBD.

 Marty asked about the cardinality of the triplet of child elements under
 Packaging.  Action item: Marty will discuss this with Dale.

 Tony questioned whether validation of ProcessSpecification references (via
 digests) should be done on an all-or-nothing basis.  After some
 discussion,
 it was agreed for phase one (at least) that if any ProcessSpecification
 reference is found to be invalid, the whole CPA is to be considered
 invalid.
 Depending on the outcome of discussions between Tony and Chris, this
 relates
 to the ProcessSpecification and/or Signature elements.

 Marty pointed out that if a pair of Parties doing business under multiple
 business processes wishes to be able to modify a single
 Process-Specification
 document without interrupting business under the others, they
 should create
 a sepaate CPA for that process.  It was noted that when a CPA references
 multiple Process-Specification Documents, it should be assumed that those
 processes are interrelated and invalidating the CPA and all of
 the Process-
 Specification documents when a problem develops with one of them is the
 correct action from a business viewpoint.


 Marty noted (at
 least) two cases where Parties might wish to test wether invalidation has
 occurred:

 1. When constructing a CPA from CPPs, the CPPs and the referenced Process
 Specification Documents could be tested to see if anything has changed
 since the CPP was constructed.

 2. Once the CPA has been installed, the Parties might want periodically
 to test it and the referenced Process-Specification Documents for
 validity.
 It was observed that when a CPA and the referenced Process-Specification
 documents are installed in a system, the information in them is generally
 digested by the installation tool and the original documents are not
 actively involved in runtime operations.  So the Parties are
 doing business
 based on the state of the CPA and Process Specification documents
 when they
 were installed and changes to these documents do not affect ongoing
 operations
 unless and until they have to be reinstalled.

 It was agreed that our document should discuss when ProcessSpecification
 references may be "cached" and when they may be checked for validity.

 Jamie noted that the Specification Schema team is making a couple of key
 assumptions regarding collaborations:

 1. There can be infinite nesting of collaborations

 2. Multi-party collaborations can always be reduced to sets of binary
 collaborations, each with a separate CPA

 Marty agreed that proceeding along the lines of #2 is consistent with the
 current state of the art in CPA processing.

 There will be no teleconference next week; our next meeting is scheduled
 for
 March 14.

 Respectfully submitted,
 Tony Weida


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

 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
 ******************************************************************
 *******************



 ------------------------------------------------------------------
 To unsubscribe from this elist send a message with the single word
 "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC