RE: IDREF vs HREF for graph edges in SOAP encoding

Chris, Henrik,

I think that whats important is the interpretation of the data and not the
artifact (processor) that does the interpretation. As I understand it the
SOAP Data Model and Encoding style was created with the intent of encoding
programming language data structures and to be interpreted as such. Our
spec. needs to say what a chunk of SOAP style encoded data means in the
context of the SOAP Data Model (note - not what the resulting graph means to
the application but what graph value is encoded).

The (little) fly in the ointment for me is whether there are different Data
Models/interpretations that we have ambition to share the same Encoding
Rules. For, there was some work (from Henrik) to explore the use of the SOAP
encoding to encode an RDF Graph [1,2]. That would yield a different data
model, different interpretation, but would/could generate an encoding that
shared the same syntactic rules. It is *not* clear to me whether or not such
dual/multiple use of the encoding is a goal that the WG is subscribed to or
whether for example it is a requirement that the RDF Core WG would like us
to address.

If there is an ambition to make multiple use of this encoding we should be
clear about that. The particular choice of IDREF/AnyURI values for denoting
graph edges *might* make a difference to what other uses our encoding may be
put to.... this may also be FUD on my part. I have not studied [1,2] enough
to know whether the choice of IDREFs for graph edges would preclude such
re-use.

Summary... if the sole purpose of the Data Model and Encoding is for
encoding programming constructs exchanged in RPC invocations then we need
not be concerned with its use for other purpose. If we have ambition that
the encoding be able to be used to encode other graph like things as well,
we might need to know a little more about those other possible uses before
we can make this choice.

Regards

Stuart
[1]
http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/SOAP-RDF_
files/frame.htm
[2]
http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/soaprdf.h
tml

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: 16 January 2002 17:15
> To: xml-dist-app@w3.org
> 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 13:24:40 UTC