[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 2/16/2004: Business Transaction Patterns WI 22 [RSD]
Discussion: OASIS.ebBP.WI22-Transaction Pattern Support; Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00145.html; Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00149.html; Topic|; Point|RequestingBusinessActivity Attribute Values; mm1@ ||Note: Attachments are to Roberts posting with the .png and .gifs for Commercial Transaction and Information Distribution. Key points to consider: * Explicit definition of business transaction patterns o This may also provide helpful for implementors (See Work Item 19 and 37, one asking about the use of BPSS instances). o Provide mechanisms to allow understanding, usage and extension of business transaction patterns o In later versions, consider accommodating explicitly dispatch/reach and offer-acceptance. The current in-work proposals do not preclude extensions to investigate these additional patterns. o In the future, this structure may allow extensibility for vertical industry or evolving business transaction patterns. * RequestingBusinessActivity attribute settings o The RequestingBusinessActivity shown is derived by restriction which means that no new attributes would be allowed. Martin Roberts has identified two options. + Set attribute settings to values as described by the document that explained the patterns (as shown in referenced attachments) # Use of prohibit for attributes that do not apply to the pattern - no override possible. + Do a similar definition (as shown in referenced attachments) except use default values to show what should be used but allow for overriding. This would mean that it would be possible to insist on Non-Repudiation with an InformationDistribution. As the link between the BusinessTransactionAcitivity and the BusinessTransaction is a IDREF (GUIDREF) there is no change to the BusinessTransactionActivity for this change. Our potential requirements as outlined in the draft white paper are: * Provide explicit definition for business transaction patterns * Consider extensibility options for business transaction patterns * Support other role, packaging and multi-party objectives * Consider how this relates to or could be impacted by WSDL proposal if any (WI 12) Martin, I support your proposals for business transaction patterns and feel the second option above is more palatable and less restrictive, yet affords the optionality that may be desired. Perhaps it today's call the team can discuss the use of default values. Thanks. @mm1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]