- From: Kevin Mitchell <kevin.mitchell@xmls.com>
- Date: Tue, 05 Dec 2000 21:01:10 GMT
- To: David "E. Cleary" <davec@progress.com>
- CC: <xml-dist-app@w3.org>
- Message-ID: <20001205.21011000@kevinm01.xmls.com>
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 mean > having binary data withing an XML document in an unencoded form. Indirect > handling of binary data through URI Reference is within scope and should be > 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 it > in a normative form. Also, there is plenty of prior work on this front from > 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 some > 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