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 12:38:28 UTC