Re: IDREF vs HREF for graph edges in SOAP encoding

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


> Henrik,
>  I was saying that it does not matter whether one uses an
> external library or an internal function. In both cases the
> deserialization process is quite independent of the application.
>
>  I'm trying to explain that IMHO the spec has two options:
>  1) to see encoding as part of the application,
>  2) to see encoding independent of the application.
>
>  In the first case Encoding may be positioned as a set of
> guidelines and it may leave some decisions (e.g. to dereference
> or not to dereference) to the application.
>
>  In the second case Encoding must handle all the cases without
> much information from the application except for the data in the
> data model. Our data model doesn't carry any information on
> whether a link should or should not be dereferenced, therefore
> the Encoding must decide. Or we can expand our data model. In my
> opinion the former is preferable to the latter.
>  The second case will also ease the implementation of SOAP
> Encoding, which should surely be considered.
>
>  Best regards,
>
>                    Jacek Kopecky
>
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
>
>
>
> On Wed, 16 Jan 2002, Henrik Frystyk Nielsen wrote:
>
>  >
>  > 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:08:24 UTC