Re: [ebxml-bp] Considerations for v20

["Anders W. Tell" <anderst@toolsmiths.se>]

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