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

RE: [DR008] - passing arbitrary content

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Tue, 5 Dec 2000 08:27:49 -0800
Message-ID: <002201c05ed8$57225ab0$fb4c1fac@redmond.corp.microsoft.com>
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Kevin Mitchell" <kevin.mitchell@xmls.com>
Cc: <xml-dist-app@w3.org>
It is important to point out that there are already ways for dealing
with so-called binary data without XP having to invent anything:

  * Data can be carried as hex encoded data within the envelope
  * Data can be referenced using a URI from within the envelope

Note also that from an XP perspective there is no difference between
"true" binary data or just some data that we don't want to express as
"active" content in the XP envelope.

One example of how to carry "binary" data is the MIME multipart/related
protocol binding that has been proposed for SOAP [1]. It supports all
data types that can be carried within a MIME body.

The mechanisms above are sufficiently flexible to support a vast set of
scenarios. However, one might put forward the argument that neither of
these solutions are particularly efficient. The part that I would say is
"out-of-scope" is that we will not in this WG define new mechanisms
(specific to XP or otherwise) for carrying "binary" data.

I would therefore suggest the wording:

As expressed in R700, XP will support carrying application specific data
within the envelope and to refer to application specific data outside
the envelope. Application specific data may be encoded as binary data.
The WG will use existing mechanisms for handling binary data such as XSD
support for binary data and the use of URIs for referening data. The WG
will not define new mechanisms for handling binary data.

Henrik

[1]
http://www.hpl.hp.com/personal/John_Barton/HTTP-A/SOAPAttachments16OCT00.htm
Received on Tuesday, 5 December 2000 11:28:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:57 GMT