W3C home > Mailing lists > Public > www-archive@w3.org > September 2002

Re: Clean up of state tables

From: Marc Hadley <marc.hadley@sun.com>
Date: Mon, 23 Sep 2002 14:28:03 -0400
Cc: "W3C Public Archive" <www-archive@w3.org>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Nilo Mitra" <EUSNILM@am1.ericsson.se>, "Noah Mendelson" <noah_mendelsohn@us.ibm.com>, "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: "Martin Gudgin" <mgudgin@microsoft.com>
Message-Id: <3274C598-CF22-11D6-8E9E-0003937568DC@sun.com>

On Sunday, Sep 22, 2002, at 20:49 US/Eastern, Martin Gudgin wrote:
> I cleaned up stuff regarding URIs for property values.
> 	Made sure all URIs that function as bases URIs have trailing
> 	Changed several occurences of soap/mep/request-response so
> soap/mep/soap-response in section 6.3
> If someone could cast an eye over it and make sure I didn't break
> anything...
Its broken, but I don't think you necessarily broke it ;-). The problem 
is the use of two different state machines in 6.2 and 6.3 that share 
the same relative names (e.g. Sending+Receiving) but now have four 
different base URIs:


The main problem with this is that the HTTP binding text tries to 
describe support for both request-response and soap-response in the 
same place (section 7.5) by only referring to the relative state names. 
This was OK before we made the state names absolute since 
Sending+Receiving was effectively one state shared by both state 
machines. Yhat was why I left the value of reqres:Role in table 9 
unchanged in my original edit - to make both state machines share the 
same state names.

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).


> I also removed generics.
> Gudge
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.
Received on Monday, 23 September 2002 14:28:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:53 UTC