W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

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

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 17 Dec 2001 10:57:37 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D05CBCFEC@red-msg-07.redmond.corp.microsoft.com>
To: "Christopher Ferris" <chris.ferris@sun.com>, "Jacek Kopecky" <jacek@systinet.com>
Cc: <xml-dist-app@w3.org>

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 Monday, 17 December 2001 13:58:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC