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

Re: IDREF vs HREF for graph edges in SOAP encoding

From: Edwin Ortega <ortegae@wns.net>
Date: Wed, 16 Jan 2002 15:05:35 -0800
Message-ID: <01ee01c19ee2$5177fca0$32a2583f@val6000>
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 GMT

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