[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Considerations for v20
>* Focus on the "Business" side of the protocol and not so much on >technical features such a XPath. > Xpath is a technical choice to be used in a condition language (shell). > Presumably the real semantics is found in the expressions referenced. Or > am I missing your point here? Perhaps you are calling for more > illustrations of usage of condition languages? Yes, technology neutrality regarding choice of condition language is a good idea and since EDIFACT must be supported it may be difficult to map business rule semantics depending on format. And no, I just wanted to keep and promote a business/legal first approach :) Could elaborate on "Presumably the real semantics is found in the expressions referenced" ? Sound interesting. >* Focus on finding support for "instrument of offer" rather than better >XML support. > Anders, I am not familiar with the implications of the quoted phrase. Is > this intended to replace the idea of "Request" somehow? Depends how you define request but if you mean transaction::request it is most likelly not to be affected. Have a look at this UN document: <http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf> The section below states that you need more than just a named transaction or document. "3.2.1 Definition of an Offer A Message constitutes an offer if it includes a proposal for concluding a contract addressed to one or more specific persons which is sufficiently definite and indicates the intention of the sender of the offer to be bound in case of acceptance. A Message made available electronically at large shall, unless otherwise stated therein, not constitute an offer." There a need for a "explicit",semantically richer specification of the content other than information entities. The offer remains after a transaction/message exhange has completed. In other words what is left after the Request is (simply put): <effect type=request"> create power id=X to create contract</effect> acceptance,reject effects are (simply put) <effect type=acceptance"> exercise power id= X</effect> <effect type=reject"> delete power id= IX</effect> UBAC need some hooks in order to be able to govern/regulate business behavior such as that party has the permission or is prohibited to do offers possibly with restrictions on characteristics of the offer (example monetary restrictions). > I hope that > lower level concepts like MEP can be properly separated from higher > business level categorizations of processes with varying intent, > presuppositions, and effects. Illocutionary and perlocutionary aspects > of utterances still can ride on acoustic waves, after all. I am all for > keeping layers clear, but in some ways, BPSS is relating how the higher > semantics cling to a (slightly abstracted) collaboration protocol layer > in carrying out their tasks. The focus must straddle both IMO. Yep, I agree. You need to be able to explain the business dialog semantics to no technichans so business/legal terminology must prevail. Yet still BPSS should be mappable to/executable in terms of lower levels where MEPs are the language of choice. There is also another dialog topic which hasnt been discussed and that is the question if breakout-dialogs should be specified for Collaborations. A breakout-dialog is a dialog about the dialog, a meta dialog. So if you are not happy with the current protocol you may branch out and discuss it separately. Similar to dispute resolution, could also be is used to correct or bypass steps in a collaboration. Bypassing is a nice feature if you want to bring out-of-band discussion/agreements into an ongoing dialog. > * Recognise that the target users are SME companies so adding technical > complexities that makes the protocol difficult to "understand" for > business users and expensive to implement should be avoided. > Will BPSS be something a SME ever sees? I doubt it. I hope we expect to > rely on GUI abstractions to protect the SME user from either the UMM/UML > or XML goo underneath. But simple is good as long as it is not overly > simple (apologies to Einstein) I too hope that business persons wont be exposed directly to XML artifacts such as BPPS but they will most certainly be exposed to the business semantics captured in the BPSS. This because the information being exchanged will in many cases involve the creation of legally relevant information which will affect the business system and balance sheets ,results, risk exposure, liabilities, warrenties etc. When teaching a business person about how they interact with their partners one most likelly will touch BPSS semantics unless BPSS is generated from somewhere else. The spillover effect is significant and this is why I love Receipt and Acceptance more than NOF. They are quite easy to explain. /anders -- ///////////////////////////////////// / Business Collaboration Toolsmiths / / website: <www.toolsmiths.se> / / email: <anderst@toolsmiths.se> / / phone: +46 8 545 885 87 / / mobile: +46 70 546 66 03 / /////////////////////////////////////
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]