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

RE: [DR008] - passing arbitrary content

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 6 Dec 2000 13:24:03 -0500
To: Paul Denning <pauld@mitre.org>
Cc: xml-dist-app@w3.org
Message-ID: <OFE3884D19.1998E94F-ON852569AD.0065ABB7@lotus.com>
Other than some slight hesitance about whether this is consistent with our 
charter, I like it.  Certainly the focus on tying it to the binding(s) 
seems right.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Paul Denning <pauld@mitre.org>
Sent by: xml-dist-app-request@w3.org
12/06/00 01:12 PM

        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        RE: [DR008] - passing arbitrary content


The statement in [1]

"The methods described here treat the multipart MIME structure as 
essentially a part of the transfer protocol binding, i.e., on par with the 

transfer protocol headers as far as the SOAP message is concerned. "

So, how about adding the following new DR6xx in section 3.6 to address 
normative XP processing:

[DR6xx] Arbitrary content (to include binary data) outside the XP message 
shall be accomodated by the protocol binding.


At 11:27 AM 2000-12-05, Henrik Frystyk Nielsen wrote:
>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.
Received on Wednesday, 6 December 2000 13:32:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:30 UTC