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

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

From: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
Date: Mon, 10 Dec 2001 15:12:50 -0500
To: andrewl@microsoft.com
Cc: "jacek" <jacek@systinet.com>, "xml-dist-app" <xml-dist-app@w3.org>
Message-ID: <OF28F1F7CD.DAC5BA86-ON85256B1E.006E988C@pok.ibm.com>

Andrew Layman asks:

>>  Can we make such normative statements
>> universally about URI reference processing
>> or should processing depend on the
>> semantics of the message? I think the latter.

Roughly, I've proposed that the core SOAP architecture anticipate SOAP +
Attachements, DIME, etc. by including a statement that transport binding
specifications SHOULD indicate which URLs (generally which schemes, but not
necesarily) are used to reference data that is carried with a message, as
distinct from all the other data on the Web.  We use URI's for both, but I
think it's useful to have a strong notion of "this data is a reference
within the message, though not necessarily within the SOAP envelope."
Note that these rules would apply to URI's anywhere in the message, not
just where SOAP can find them.  If the application finds a URI pointing to
an attachement, we should specify the general characteristics of a
dereference of that URI, I think.

That's all I meant.   Once you've got that, you can start to ask how you'd
want the encodings to behave in the face of one or the other reference.
Perhaps the behavior would be the same for attachments and other web
references, perhaps not.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
Received on Monday, 10 December 2001 16:19:58 UTC

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