Re: IDREF vs HREF for graph edges in SOAP encoding

Stuart,

IMO, RDF encoding is a completely separate thing from
SOAP encoding. While there may be similarities, they would
be quite distinct because RDF carries its own semantics.

Cheers,

Chris

Williams, Stuart wrote:

> 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 14:41:05 UTC