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

Re: IDREF vs HREF for graph edges in SOAP encoding

From: Christopher Ferris <chris.ferris@sun.com>
Date: Wed, 16 Jan 2002 12:15:26 -0500
Message-ID: <3C45B52E.9060309@sun.com>
To: xml-dist-app@w3.org
Henrik,

I'm trying to understand what you're suggesting here.

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?

While it might be reasonable to state that there *might not be*
a separate entity that performs (de|en)coding of application
data, I don't believe that we should therefore preclude the
opposite (that there *might be* a separate function, independent
of the application context).

I think that while it is likely that many do have in their
mind an implementation design that incorporates a separate
function that performs (de|en)coding of application data,
that that is a perfectly reasonable way to view the problem
so long as it doesn't necessarily preclude alternate
solutions that do not share a similar design center.

What you seem to be suggesting here is that there cannot/must not
be a separate (de|en)coding process that is independent of
the application. I'm not so sure that many would agree with
this position.

Cheers,

Chris

Henrik Frystyk Nielsen wrote:

> 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 12:16:48 GMT

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