Re: issue 168 proposal: xsi:type of external references in Encoding (fwd)

Henrik,

Agreed that using IDREF provides no guarantees that the
graph is closed, etc. However, what it does do is provide
the deserialization mechanism with an understanding that
if it finds that the referenced node is not present,
that that is an error and it can respond with a Fault.
It also provides the receiving node with an understanding
that it need do nothing special to resolve the referenced
nodes.

Cheers,

Chris

Henrik Frystyk Nielsen wrote:

> Chris,
> 
> While I see your point, I don't agree that restricting the value space
> of references help in any way other than dodging the issue by saying
> that whatever can't be serialized with IDREF is up to the application.
> Using IDREF provides no particular guarantees that the closed graph is
> coherent, complete, or in any other way valid. It simply limits the
> potential value space in what I consider an artificial manner. 
> 
> As href is a strict superset of IDREF I am wondering whether it would
> not be possible to indicate that links used in the SOAP encoding SHOULD
> be made as relative as possible. That is, we establish a convention for
> the preferred way to indicate the references:
> 
> 	1) relative within document (#foo)
> 	2) relative to document (includes SwA, DIME, etc.)
> 	3) absolute
> 
> In other words, if people *do* depend on external resources then the
> href/IDREF distinction makes no difference. If they *don't* then it also
> makes no difference because the values are all relative.
> 
> Henrik
> 
> 
>>If there is need to reference data externally (e.g. SwA
>>or on the web, etc.) then this is strictly application
>>data and semantics that has nothing to do with SOAP encoding 
>>and everything to do with the application semantics. The SOAP 
>>encoding href is NOT to be used to express this application 
>>semantic. It is just data to be serialized.
>>
>>This allows for us to say that if the IDREF doesn't resolve
>>to a node in the SOAP envelope document, that the 
>>deserialization mechanism can assert that there is a problem 
>>and return a Fault.
>>
>

Received on Tuesday, 18 December 2001 07:29:43 UTC