Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Cc: "Marc Hadley" <marc.hadley@sun.com>; "Martin Gudgin"
<marting@develop.com>; <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 8:55 AM
Subject: 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 12:31:15 UTC