Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: "Marc Hadley" <marc.hadley@sun.com>; "Martin Gudgin"
<marting@develop.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>; <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 7:59 AM
Subject: RE: IDREF vs HREF for graph edges in SOAP encoding


>
> 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:30:54 UTC