Re: IDREF vs HREF for graph edges in SOAP encoding

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 UTC