RE: IDREF vs HREF for graph edges in SOAP encoding

 Henrik, 
 every usable SOAP implementation I know of does have a SOAP 
Encoding layer for serialization and deserialization.
 If we assumed your position, IMHO SOAP Encoding would become a
set of (tight or vague, pick one) rules for serializing some data
in some data models (not necessarily one). But since XML Schema
is a rec I think we don't need such SOAP Encoding. See Gudge's 
original email re: "Section 5 vs Schema", I think he assumed 
exactly your position in the email.
 On the other hand if we view SOAP Encoding as the encoding of 
SOAP Data model, the data model of SOAP RPC, and we define all 
three of them strictly, it just implies some kind of Encoding 
processor because the Encoding layer would be quite separated 
from the application layer.
 It might be an implementation choice creeping into the spec, but
then a) it's only in Encoding, b) it's the choice of great many
implementations, c) it's logical (OK, at least to me). We want
SOAP to be simply implementable and usable, don't we? If we
permit (and in fact, encourage) SOAP Encoding processing, using
SOAP stacks to create web services will be very easy. If we
require every application to do its own XML (de)serialization, it
will increase the barrier significantly.
 And by an Encoding processor I mean an external library, too (as
opposed to internal subsystem of a SOAP stack), because the 
functionality is equivalent. Such a library would have exactly 
the same problems as an internal subsystem of a SOAP stack.
 Best regards,

                   Jacek Kopecky

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



On Wed, 16 Jan 2002, Henrik Frystyk Nielsen wrote:

 > 
 > It seems that the fundamental reason for the request of changing from
 > the current situation is the assumption that that there is a special
 > SOAP encoding/decoding processor that does things independently of the
 > application data whose data it encodes/decodes. That is, for decoding in
 > particular, the SOAP encoding processor decodes the data and passes it
 > to the application in some internal representation.
 > 
 > I disagree this is the case - we have exactly one processor which is the
 > SOAP envelope processor. There is in my opinion no such thing as a SOAP
 > encoding/decoding processor. The transport task force went through
 > considerable discussion on a related issue of whether the protocol
 > binding provides a processor or not and came to the conclusion that it
 > does not. I don't think the situation is any different for the encoding.
 > 
 > One of the arguments seems to be that it makes things simpler for this
 > "SOAP encoding processor" to deal with an instance if it doesn't have to
 > make the choice of whether to dereference a URI reference or not.
 > 
 > IMO this is a clear example of implementation choices creeping into our
 > considerations. Whether a URI reference is dereferenced or not
 > regardless of the type of the reference is a choice of the application
 > and not of SOAP. The application should make that determination based on
 > the semantics of the data of which, by definition, SOAP is unaware.
 > 
 > >Yes, with the clarification that the restriction on "direct 
 > >references" 
 > >would only apply to graph edges within the encoding. Element content 
 > >could still be of type anyURI and refer to anything.
 > 
 > Henrik
 >

Received on Wednesday, 16 January 2002 11:55:03 UTC