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

RE: [DR040] - Binary data

From: Kevin Mitchell <kevin.mitchell@xmls.com>
Date: Tue, 05 Dec 2000 21:01:10 GMT
Message-ID: <20001205.21011000@kevinm01.xmls.com>
To: David "E. Cleary" <davec@progress.com>
CC: <xml-dist-app@w3.org>
I think this will be difficult to accomplish without limiting the 
applicability of the protocol, because of the following...

The optimal method for dealing with binary data will depend largely on 
the nature of information being exchanged using XP. So, it will be 
difficult to select a single mechanism without introducing inefficiencies 
for one application or another. It will also be difficult (and confusing 
IMHO) to specify mulitple mechanisms that together attempt to handle all 
cases optimally. Consider the following two scenarios:

Scenario 1: Consider an icon registry application. The application wishes 
to accept icons in the form of JPEG data. Since icons are relatively 
small, it is convenient to include the JPEG icon data within the icon 
publishing request. In this case, simply base64-encoding the icon is an 
attractive solution while referencing the icon data with a URI is 
somewhat inefficient.

Scenario 2: Consider a Napster-like catalog system. Publishers advertise 
the availability of a audio file in a centralized catalog. Consumers then 
browse the catalog and select audio files for download or immediate 
listening. Additionally, publishers require the ability to update the 
content of the file without updating the central catalog. In this 
scenario, due to the potentially large size of the audio files, and the 
need for decentralized content management, URIs are convenient for 
conveying the binary data. For the same reasons, base64 encoding or 
inclusion in a MIME/multipart package are inconvenient.

Note that both scenarios (and XForms requirement 3) will be supported by 
XP without a requirement for binary data handling, because of R401 and 
R403. Also, having a requirement to establish a normative method for 
handling binary data may conflict with DR700, which talks about the need 
for application-specific content.

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 12/5/00, 10:14:46 AM, David "E." Cleary <davec@progress.com> wrote 
regarding RE: [DR040] - Binary data:

> > Given that binary data support is out of scope, but there is room to
> > examine such issues if there is interest and time, I propose that DR040
> > be reworded as a WG statement, and not as an explicit requirement.

> "Direct" handling of binary data is out of scope, which I construe to 
> having binary data withing an XML document in an unencoded form. Indirect
> handling of binary data through URI Reference is within scope and should 
> supported. It is a requirement of XForms to be able to submit data that
> includes binary data, and the XForms WG would prefer to have XP specify 
> in a normative form. Also, there is plenty of prior work on this front 
> SOAP, ebXML, and other standards. I strongly believe indirect handling of
> binary data is a requirement of XP. We know most are going to require 
> form of this, and not specifying it in a normative fashion will just kill
> interoperability.

> David Cleary
> Progress Software
Received on Tuesday, 5 December 2000 16:00:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC