- From: Jacek Kopecky <jacek@systinet.com>
- Date: Thu, 8 Nov 2001 14:54:00 +0100 (CET)
- To: Rich Salz <rsalz@zolera.com>
- cc: Martin Gudgin <marting@develop.com>, XML Protocol Discussion <xml-dist-app@w3.org>
Rich,
you mean turning the fault into a data. Your problem is that the
fault is not encoded in such a way that it could be marked as
following the Encoding rules and it would be a legal
serialization according to the rules, right?
Faults are a part of the core SOAP, Encoding is an optional
adjunct so we should not make the faults follow the encoding
rules explicitly.
IMHO keeping an implicit relationship is PITA to maintain and we
cannot make any guarantees about it (because it would make the
relationship explicit and Encoding would have to be moved to core
and all that) so I think that serializing faults and _breaking_
the Encoding rules might be the best way to go to avoid problems
later.
Best regards,
Jacek Kopecky
Senior Architect, Systinet (formerly Idoox)
http://www.systinet.com/
On Thu, 8 Nov 2001, Rich Salz wrote:
> The proposal that uses attributes to encode fault data are a problem.
>
> Imagine A->B->C. C faults, and B would like to send that fault *as data*
> back to A. Because the code is an attribute, it doesn't fit with SOAP
> Encoding / SOAP RPC.
> /r$
>
Received on Thursday, 8 November 2001 08:54:03 UTC