- From: Edwin Ortega <ortegae@wns.net>
- Date: Wed, 16 Jan 2002 15:05:35 -0800
- To: "Christopher Ferris" <chris.ferris@sun.com>, "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: <xml-dist-app@w3.org>
----- Original Message ----- From: "Christopher Ferris" <chris.ferris@sun.com> To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Cc: <xml-dist-app@w3.org> Sent: Wednesday, January 16, 2002 10:29 AM Subject: Re: IDREF vs HREF for graph edges in SOAP encoding > 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 14:08:22 UTC