Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Christopher Ferris" <chris.ferris@sun.com>
To: <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 9:15 AM
Subject: 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 14:06:55 UTC