Re: Clean up of state tables

On Monday, Sep 23, 2002, at 15:53 US/Eastern, Martin Gudgin wrote:

> Isn't the only place that 'RequestingSOAPNode' and 'RespondingSOAPNode'
> only appear at the very top of 7.5.
>
> Why not just change the bullets to read
>
> For binding instances conforming to this specification:
>
> 	A SOAP node instantiated at an HTTP client may assume the role
> (i.e. the property reqres:Role ) of
> "http://www.w3.org/2002/06/soap/mep/request-response/ 
> RequestingSOAPNode"
> or  
> "http://www.w3.org/2002/06/soap/mep/soap-response/RequestingSOAPNode"
>
> 	A SOAP node instantiated at an HTTP server may assume the role
> (i.e. the property reqres:Role ) of
> "http://www.w3.org/2002/06/soap/mep/request-response/ 
> RespondingSOAPNode"
> or  
> "http://www.w3.org/2002/06/soap/mep/soap-response/RespondingSOAPNode"
>
>
> Would that work?
>
The following two paragraphs might also need to be changed:

<current>The remainder of this section describes the MEP state machine  
and its relation to the HTTP protocol. In the state tables below, the  
states are defined as values of the property reqres:State (see 6.2 SOAP  
Request-Response Message Exchange Pattern), and are of type xs:anyURI .  
For brevity, relative URIs are used, the base URI being the value of  
reqres:Role .</current>

We might just be able to add a reference to 6.3, but then the baseURI  
would be different depending on whether you were executing  
soap-response or request-response state machines. How would the  
participants agree which state machine they were executing, would it  
matter if they disagreed (probably not in this case, indicating that we  
don't need two separate state machines).

<current>Failure reasons that are specified in the tables represent  
values of the property context:FailureReason and their values are  
relative URIs whose base URI is the value of  
context:ExchangePatternName . If an implementation enters the "Fail"  
state, the context:FailureReason property will contain the value  
specified for the particular transition.</current>

I think there's also duplication of failure states between the two  
state machines so I'm not sure we need both.

Marc.


> Gudge
>
>
>
>> -----Original Message-----
>> From: Marc Hadley [mailto:marc.hadley@sun.com]
>> Sent: 23 September 2002 12:46
>> To: Martin Gudgin
>> Cc: W3C Public Archive; Jean-Jacques Moreau; Nilo Mitra; Noah
>> Mendelson; Henrik Frystyk Nielsen
>> Subject: Re: Clean up of state tables
>>
>>
>> On Monday, Sep 23, 2002, at 15:19 US/Eastern, Martin Gudgin wrote:
>>>>
>>>> I think we have two options:
>>>>
>>>> (i) rethink the base URI for the states such that they are
>> shared by
>>>> both request-response and soap-response - or -
>>>> (ii) Split section 7.5 into two, one for each state machine.
>>>>
>>>> I'd prefer (i) but LC issue 305 might push our choice to (ii).
>>>
>>> It seems to me that (ii) is probably easier and quicker for us as
>>> editors to implement.
>>>
>> I disagree, (i) is *much* easier editorially, just change a base URI
>> here and there. (ii) is a lot of work, will make the document
>> significantly longer (lots of duplication required) and I
>> hate editing
>> those state transition tables !
>>
>> Marc.
>>
>> --
>> Marc Hadley <marc.hadley@sun.com>
>> XML Technology Center, Sun Microsystems.
>>
>>
>
>
--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.

Received on Monday, 23 September 2002 16:10:12 UTC