Re: IDREF vs HREF for graph edges in SOAP encoding

----- Original Message -----
From: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
To: "Jacek Kopecky" <jacek@systinet.com>
Cc: "Marc Hadley" <marc.hadley@sun.com>; "Martin Gudgin"
<marting@develop.com>; <xml-dist-app@w3.org>
Sent: Wednesday, January 16, 2002 9:37 AM
Subject: RE: IDREF vs HREF for graph edges in SOAP encoding


>
> I think you might be missing my point. It is simply not within our scope
> to determine whether one uses an external library or an internal
> function.
>
> You are perfectly welcome to make any implementation choice you wish in
> order to make it easier for users using your software to write apps
> faster and better. This is, however, not a spec issue but an
> implementation issue. This includes how you decide to resolve references
> of any kind.
>
> Henrik
>
> >-----Original Message-----
> >From: Jacek Kopecky [mailto:jacek@systinet.com]
> >Sent: Wednesday, January 16, 2002 08:55
> >To: Henrik Frystyk Nielsen
> >Cc: Marc Hadley; Martin Gudgin; xml-dist-app@w3.org
> >Subject: RE: IDREF vs HREF for graph edges in SOAP encoding
> >
> >
> > Henrik,
> > every usable SOAP implementation I know of does have a SOAP
> >Encoding layer for serialization and deserialization.
> > If we assumed your position, IMHO SOAP Encoding would become a
> >set of (tight or vague, pick one) rules for serializing some data
> >in some data models (not necessarily one). But since XML Schema
> >is a rec I think we don't need such SOAP Encoding. See Gudge's
> >original email re: "Section 5 vs Schema", I think he assumed
> >exactly your position in the email.
> > On the other hand if we view SOAP Encoding as the encoding of
> >SOAP Data model, the data model of SOAP RPC, and we define all
> >three of them strictly, it just implies some kind of Encoding
> >processor because the Encoding layer would be quite separated
> >from the application layer.
> > It might be an implementation choice creeping into the spec, but
> >then a) it's only in Encoding, b) it's the choice of great many
> >implementations, c) it's logical (OK, at least to me). We want
> >SOAP to be simply implementable and usable, don't we? If we
> >permit (and in fact, encourage) SOAP Encoding processing, using
> >SOAP stacks to create web services will be very easy. If we
> >require every application to do its own XML (de)serialization, it
> >will increase the barrier significantly.
> > And by an Encoding processor I mean an external library, too (as
> >opposed to internal subsystem of a SOAP stack), because the
> >functionality is equivalent. Such a library would have exactly
> >the same problems as an internal subsystem of a SOAP stack.
> > Best regards,
> >
> >                   Jacek Kopecky
> >
> >                   Senior Architect, Systinet (formerly Idoox)
> >                   http://www.systinet.com/
> >
> >
> >
> >On Wed, 16 Jan 2002, 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:07:51 UTC