Re: State alignment

Hi,

Mark Baker wrote:

>>of its lifecycle) ?
>>    
>>
> A few questions though , how, when is this endpoint constructed (start
>
>
>In general, when its identity is established.  Consider an interaction
>where a purchase order is POSTed to a purchase order processor
>(identified by its own URI), and the client receives a 201 response
>back containing a URI identifying the order.  In that case the URI
>is formed at the time the agreement is formed.
>  
>
<AWT>
Its most likelly the offer that is associated with a uri, or maybe an 
agreement in state 'offered'. Its a small but significant, vital change 
since agreements are formed with consent (propose, withdraw, revoke, 
accept, reject,..)
</AWT>

> <AWT>
>
>>In some case it would be true that 2XX could have the same effect, but 
>>in a multiphop environment with many SOAP nodes returning 2XX, the 
>>meaning of 2XX becomes muddled. The "Reciept" message/signal has legal 
>>meaning and is mentioned in national and international laws and as such 
>>must be very vell defined.
>></AWT>
>>    
>>
>
>I really don't think that's a problem.  2xx means what it says in the
>HTTP spec, and SOAP (1.1 and 1.2) doesn't change that; I made sure of
>this during my time in the XML Protocol WG.  Though that doesn't stop
>people misusing it, that's their problem.
>  
>
<AWT>
It depends from which endpoint the 2XX comes from,
- an intermediary that acts in name of or on senders behalf,
- an intermediary that acts in name of, or  indended addressees behalf
- or from an information system controlled by the indeded addressee.
</AWT

>><AWT>
>>There is another interpretation of messages/communicative acts such 
>>UN/CEFACT::BPSS::AcceptanceAcknowledge
>>which is: NO means EarlyRejection. YES means continued processing. It is 
>>*extremly* important to differentiate these types of data messages from 
>>Contractual Acceptence.
>>    
>>
>
>Interesting.  But note that a multi-state transaction like that need
>not have fine-grained response codes, but instead need only model the
>transaction as a resource whose state evolves over time.
>  
>
<AWT>
Agree, but the contractual formations process comes from international 
and national LAW and should be understood and supported first hand by 
any framework claiming to be global and for eBusiness purposes.
A difference from a endpoint-state point of view is that the 
sender/originator and reveiver/indended addresse have matching but 
different statemachines. So two statemachines exists.
Another difference that affects the statemachines are that the 
statemachines are slightly different if a non-instantanous protocol 
(email, store-forward, pul) is used in kontrast  to instantanous (htttp, 
chat, etc) and if the sender or receiver is responsible to make sure the 
message get to its intended destination.
</AWT>


Thanks
/anders

Received on Sunday, 18 July 2004 08:54:36 UTC