RE: [DR008] - passing arbitrary content

Henrik,

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

There are some practical issues with both of these options. Hex encoding
effectively
doubles the size of content. If the group consensus is to NOT support native
binary
payloads then I would suggest using base64 encoding, it's more efficient
than hex encoding.

Accessing binary data thru a URI (pass be reference semantics) requires
binary data to be accessible
from the Internet (in e-commerce scenarios), for example on a web (or FTP)
server. This opens the door to
security issues, especially access control issues. For example, suppose the
binary
data is a medical X-ray. It's very likely this data would be protected by
access
control (username/password or similar).

IMHO, this additional level of redirection makes the XP protocol more
complicated, pass by reference access procedures need to be
documented/defined and error handling/reporting must be addressed.

Also related to "arbitrary content", I believe XP needs to specify how
complete XML documents are encapsulated in an XP PDU. Here again,
conventional practice is to base64 encode complete XML documents for
transport in a SOAP PDU.

Energy companies frequently exchange geographic images and other binary data
types. Several people on the SOAP list have indicated their desire for SOAP
to support native binary data, the ebXML folks have also identified this
need. I believe XP would be considered, by many, to be disadvantaged if it
didn't contain direct support for binary and XML payloads.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Henrik Frystyk Nielsen
> Sent: Tuesday, December 05, 2000 10:28 AM
> To: Jean-Jacques Moreau; Kevin Mitchell
> Cc: xml-dist-app@w3.org
> Subject: RE: [DR008] - passing arbitrary content
>
>
> 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/SOAPAttachments1
6OCT00.htm

Received on Tuesday, 5 December 2000 18:01:48 UTC