Re: [ebxml-bp] Signals suggestions

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

Thank you Martin for these suggestions which I support.

I belive it is an excellent idea to separatelly define transaction 
patterns/type and relate them to signal/message definitions.  
Subclassing a general but empty (maybe only request message is defined) 
transaction is a good modeling practice.

I offer the following texts from the legal conventions for consideration
*  "UNCITRAL Model Law on Electronic Commerce", as 85th plenary meeting 
16 December 1996
* US "UNIFORM ELECTRONIC TRANSACTIONS ACT (1999)"

These particular articles and sections show that is also important to 
address "dispatch" and "reach" of messages and signals. By reading legal 
ecommerce conventions is is clear that a legal effect could be defined 
at time of dispatch OR reach.
Clearly by adding seperate message and signal specification for 
transactions types this will assist in defining specific Dispatch, Reach 
conditions in CPA and later UBAC TPA.


"/Article 15.  Time and place of dispatch and receipt of data messages/

(1)  Unless otherwise agreed between the originator and the addressee, 
the dispatch of a data message occurs when it enters an information 
system outside the control of the originator or of the person who sent 
the data message on behalf of the originator.

(2)  Unless otherwise agreed between the originator and the addressee, 
the time of receipt of a data message is determined as follows:

    (a) if the addressee has designated an information system for the
    purpose of receiving data messages, receipt occurs:

    (i) at the time when the data message enters the designated
    information system; or

    (ii) if the data message is sent to an information system of the
    addressee that is not the designated information system, at the time
    when the data message is retrieved by the addressee;

    (b) if the addressee has not designated an information system,
    receipt occurs when the data message enters an information system of
    the addressee.

(3)  Paragraph (2) applies notwithstanding that the place where the 
information system is located may be different from the place where the 
data message is deemed to be received under paragraph (4).

(4)  Unless otherwise agreed between the originator and the addressee, a 
data message is deemed to be dispatched at the place where the 
originator has its place of business, and is deemed to be received at 
the place where the addressee has its place of business. For the 
purposes of this paragraph:

    (a) if the originator or the addressee has more than one place of
    business, the place of business is that which has the closest
    relationship to the underlying transaction or, where there is no
    underlying transaction, the principal place of business;

    (b) if the originator or the addressee does not have a place of
    business, reference is to be made to its habitual residence.

(5)  The provisions of this article do not apply to the following: [...].

"

"SECTION 15. TIME AND PLACE OF SENDING AND RECEIPT.
(a) Unless otherwise agreed between the sender and the recipient, an
electronic record is sent when it:
(1) is addressed properly or otherwise directed properly to an
information processing system that the recipient has designated or uses 
for the
purpose of receiving electronic records or information of the type sent 
and from
which the recipient is able to retrieve the electronic record;
(2) is in a form capable of being processed by that system; and
(3) enters an information processing system outside the control of the
sender or of a person that sent the electronic record on behalf of the 
sender or enters
a region of the information processing system designated or used by the 
recipient
which is under the control of the recipient.
(b) Unless otherwise agreed between a sender and the recipient, an
electronic record is received when:
(1) it enters an information processing system that the recipient has
designated or uses for the purpose of receiving electronic records or 
information of
the type sent and from which the recipient is able to retrieve the 
electronic record;
and
(2) it is in a form capable of being processed by that system.
(c) Subsection (b) applies even if the place the information processing
system is located is different from the place the electronic record is 
deemed to be
received under subsection (d).
(d) Unless otherwise expressly provided in the electronic record or agreed
between the sender and the recipient, an electronic record is deemed to 
be sent from
the sender’s place of business and to be received at the recipient’s 
place of business.
For purposes of this subsection, the following rules apply:
(1) If the sender or recipient has more than one place of business, the
place of business of that person is the place having the closest 
relationship to the
underlying transaction.

(2) If the sender or the recipient does not have a place of business, the
place of business is the sender’s or recipient’s residence, as the case 
may be.
(e) An electronic record is received under subsection (b) even if no
individual is aware of its receipt.
(f) Receipt of an electronic acknowledgment from an information processing
system described in subsection (b) establishes that a record was 
received but, by
itself, does not establish that the content sent corresponds to the 
content received.
(g) If a person is aware that an electronic record purportedly sent under
subsection (a), or purportedly received under subsection (b), was not 
actually sent
or received, the legal effect of the sending or receipt is determined by 
other
applicable law. Except to the extent permitted by the other law, the 
requirements of
this subsection may not be varied by agreement.
Source: UNCITRAL Model Law on Electronic Commerce Article 15."


However I dont support that these issues are related to any external 
context transformations. I strongly suggest to attack the issues within 
the BP model before adding external features.

/Anders W.Tell


martin.me.roberts@bt.com wrote:

>As part if the F2F we have discussed the signals issues. Two in particular.
>
>The first is how does anyone know which signals content will be used within a given exchange.  The second was a request from Dale Moberg to have a more explicit explanation of when signals would occur and what is allowed to occur.
>
>The solution to the first is simple:  We add a set of signal definitions, similar to the document envelope definitions that allows for each of the signals to be defined.  For this there are two options 1) have a discrete set of signals that must be defined 2) have a flexible structure that allows for any type of signal to be attached.
>
>With the first option (discrete set of signal defn) we can neatly hook int the existing patterns, but would find that we could not handle other type of business exchanges outside the existing set.
>
>This links into the next problem which was how to make it absolutely clear when they would be sent.  My suggestion is that we do two things:
>
>1) instead of having BusinessTransaction as a fixed structure we introduce a set of subclasses of it that represent the patterns we wish to represent.  These transaction subclasses would define the various parameters required with default values etc and would also describe which signals applied and their appropriate timings.
>
>2) make it absolutely clear which timings are linked with which signal or document.  
>
>With these two modifications we could allow BPSS to offer support for the default set of patterns, but also we could allow other external subclasses of patterns to be developed to cover off use cases such as those that Anders Tell has requested (revocation based negotiations).  As these would not be directly in BPSS, people such as the UBAC team could trial their use before getting them adopted into later BPSS versions.
>
> 
>
>There is a catch though.  For the first time the schema of BPSS would be designed to be extended.  This would require the use of schema extension models such as the Venetian Blind (noah's ark) in a similar manner to the OAG.  Personally I use this technique in my Business documents and have been grateful for the flexibilty it offers.  However, it will mean a change to the way the CPA can manipulate timings etc, which leads me to think that this is also linked with the debate on the external context device.
>
>Again take care.
>
>Martin
>
>  
>
>------------------------------------------------------------------------
>
>Work  Items 61 and  59
>
>
>In the BPSS today there is no mechanism to describe which actual signals are  being used with the patterns.
>
>The two proposals are needed to solve this:
>
>1) allow the BPSS to refer signal descriptions of the signals in a similar fashion as the document envelope document descriptions.  As there are a standard set of signals refered to by the patterns these should be defined directly under the ProcessSpecification element.  I propose that there are 5 possible signals defined:
>
>	receiptAcknowledgement
>	receiptAcknowledgementException
>	acceptanceAcknowledgement
>	acceptanceAcknowledgementException
>
>	and if we agree 
>
>	generalException
>
>under these would be the fields that are used to describe document contents:
>
>	specificationLocation
>	specificationID
>	specigicationType
>	specificationTypeOther
>
>	plus a ConditionExpression Element to add to the specification... fields
>
>2)  Also linked to this is a clear explanation of the causes of the particular signals.  Dale Moberg asked to have a clearer definition of when these signals are to be used.  This could be sorted by more explicit definition of the use of patterns so that the BusinessTransaction element is overloaded with pattern specific types.
>
>3) workitem 59 talks about the use of an optismistic approach with failures.  There may have to be a new set of patterns to cope with this.
>	
>  
>


-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////