- From: Mark Baker <distobj@acm.org>
- Date: Wed, 3 Apr 2002 15:30:32 -0500
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Cc: Martin Gudgin <marting@develop.com>, Marc Hadley <marc.hadley@sun.com>, Christopher Ferris <chris.ferris@sun.com>, xml-dist-app@w3.org
+1 I don't think this solves any problems, does it?. I'd also be surprised if it didn't break something in the spec, because of some written-in assumption about the existing structure. Somebody would have to check that. Anyhow, it seems quite a drastic change to make this late in the process. I also don't see how it impacts 192/12. The same question - what does a fault over 200 mean - can be asked even with this new envelope structure. But I'll respond about that shortly ... MB On Wed, Apr 03, 2002 at 11:58:29AM -0800, Henrik Frystyk Nielsen wrote: > > Hmm, from an architectural point of view, I am somewhat uncomfortable > make a fault special in this regard - it seems to break orthogonality > between the envelope and faults. IMO, even though we in part 1 define a > SOAP fault as the only "message-type", processing-wise the SOAP fault is > separate from the envelope in that it defines its own semantics (what > does "faultcode" mean etc.) > > >From a practical point of view, it also seems to make the description of > the envelope more complicated as it would mean that we can't talk about > the body anymore as a unique thing. I think we already have the > possibility for carrying SOAP fault EII even though they may not "count" > as faults because a SOAP fault is *only* a SOAP fault in the processing > sense *if* it is located as the first child EII of the body EII. > > Henrik Frystyk Nielsen > mailto:henrikn@microsoft.com > > >I think that if people want to transmit other stuff with the > >fault then it > >goes in 'detail'. We place zero restriction on what goes in there... -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Wednesday, 3 April 2002 15:24:54 UTC