- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Wed, 16 Jan 2002 07:59:30 -0800
- 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 UTC