W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

RE: IDREF vs HREF for graph edges in SOAP encoding

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Wed, 16 Jan 2002 07:59:30 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D0297D0E3@red-msg-07.redmond.corp.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>

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:00:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT