- From: Martin Gudgin <marting@develop.com>
- Date: Tue, 30 Oct 2001 16:30:20 -0000
- To: "Jacek Kopecky" <jacek@systinet.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>
- Cc: <xml-dist-app@w3.org>
The issues are orthogonal. But if we decide to make one change ( hence breaking existing implementations ) it would probably also be worth making the other. Gudge ----- Original Message ----- From: "Jacek Kopecky" <jacek@systinet.com> To: "Jean-Jacques Moreau" <moreau@crf.canon.fr> Cc: <xml-dist-app@w3.org> Sent: Tuesday, October 30, 2001 2:10 PM Subject: Re: Issue 143: Client and Server fault code names > Hi. 8-) > I think that the impact on current implementations would not be > too big as the implementations already have to change the > namespace URIs to check against so this change can be > incorporated as well. > And I think, as Gudge already has pointed out (thanks, Gudge) > that issue 130 is related and might be considered at the same > time, but on the other hand, while related, the issues are > orthogonal so not considering them together won't make any harm. > Best regards, > > Jacek Kopecky > > Senior Architect, Systinet (formerly Idoox) > http://www.systinet.com/ > > > > On Tue, 30 Oct 2001, Jean-Jacques Moreau wrote: > > > Issue 143 below is currently marked as editorial: > > > > Table speaks of 'Client' faults and 'Server' faults. I > > think that this is the only place where the notion of > > 'Client' and 'Server' arise. Concepts of 'Client' and > > 'Server' are not developed anywhere in the document. > > > > It seems to me that 'Client' is more akin to 'Sender' > > and 'Server' is more akin to 'Recipient'. Regardless, > > I'm not sure personnally that 'Client' and 'Server' are > > appropriate distinctions to make in a generic SOAP > > messaging framework. > > > > The editors suggest that, in the prose, we amend 'Client' to read > > 'Sender' and 'Server' to read 'Receiver'. > > > > However, the editors wonder whether they sould also be changing > > the fault codes to match. Advantage: this would make the spec > > more consistent. Disadvantage: possible impact on existing > > implementations. > > > > Jean-Jacques. > > > > >
Received on Tuesday, 30 October 2001 11:31:20 UTC