Re: Proposal for hierarchical fault codes

 Rich,
 such a goal, if explicit, would imply that everybody and their
pet would have to know SOAP Encoding. This would make Encoding
core.
 We can restrict the goal a bit - let the spec say:
 "The XML structure of fault is modeled as compatible with the
Encoding rules (see Adjuncts) but it does not require Encoding
processing; i.e. it is deserializable using Encoding
deserializer, it MUST be serialized in a fixed way indicated by
the schema." I don't know what other structures would be
affected, certainly not Header nor Body because both can contain
multiple elements of the same name and still not be arrays.
 I am opposed to the notion of multistructures in SOAP Encoding.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Thu, 8 Nov 2001, Rich Salz wrote:

 > >  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?
 >
 > 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.
 >
 > If there is no compelling need to make a data structure incompatible
 > with SOAP Encoding, then I am strongly in favor of making it possible to
 > "naively" and "obviously" use SOAP Encoding to express that data
 > structure as it moves from XML to a native programming language
 > representation and back again.
 >
 > Making it a goal that core SOAP data structure are compatible with SOAP
 > Encoding does not mean that Encoding now becomes part of the core.
 > 	/r$
 >
 >

Received on Thursday, 8 November 2001 10:42:52 UTC