- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Wed, 16 Jan 2002 13:29:46 -0500
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- CC: xml-dist-app@w3.org
No, but what you're suggesting is that only the application can determine whether or not an unresolvable reference constitutes an error, something that can be ignored, or something that the application needs to dereference on its own. If the data that is represented as a reference is indeed remote (external to the SOAP Envelope), then I for one would much prefer that this be modeled as a reference "type" (xsi:type="anyURI") where the URI is the "value" of that type (and is reflected in the content of the element representing that data item), and where the dereferencing of that "value" were an application function. Cheers, Chris Henrik Frystyk Nielsen wrote: > Yes, the SOAP spec doesn't define an encoding/decoding processor; it > defines for better or for worse a mechanism by which data can be encoded > based on the SOAP data model. How that mechanism is implemented is > entirely up to the implementer. IMO, as spec writers we have nothing to > say about specific implementation choices. In this context, I do not > preclude or assume any of the possible solutions you mention. > > Henrik > > >>Are you suggesting that the SOAP spec(s) don't define >>an entity equivalent to the "SOAP (de|en)coding processor" >>and hence we have nothing to say about it? Or, are you >>suggesting that in your view, the (de|en)coding function is >>exclusively an "application" function and hence we have >>nothing to say about it? >>
Received on Wednesday, 16 January 2002 13:31:17 UTC