- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 19 Oct 2005 13:46:11 -0700
- To: "Sanjiva Weerawarana" <sanjiva@opensource.lk>, "Hugo Haas" <hugo@w3.org>
- Cc: "WS-Description WG" <www-ws-desc@w3.org>
> -----Original Message----- > From: www-ws-desc-request@w3.org > [mailto:www-ws-desc-request@w3.org] On Behalf Of Sanjiva Weerawarana > Sent: Tuesday, Oct 18, 2005 6:39 PM > To: Hugo Haas > Cc: WS-Description WG > Subject: Re: describing a service that returns an image/jpg > (for example) > > > On Tue, 2005-10-18 at 18:06 +0200, Hugo Haas wrote: > > That's a nice trick which I think works, and works well for binary > > content. However, in LC337, the DAWG talks about HTML, plain text, > > RDF. Won't they be forced to declare say their RDF as > Base64-encoded? > > I know that sucks, but that's the reality of SOAP (and XML > really): You > can't embed HTML without base64 encoding it. Nor can you embed an XML > document in SOAP without encoding it. If application/rdf+xml > is used to > carry an entire XML *document*, then there's no option but to > encode it > to carry it in SOAP. > > Text is slightly special and can obviously be done with just escaping > instead of encoding but IMO its not worth special casing. A big +1. We had the same discussions during the media types document work and realized that there is simplicity in the restriction and restricted ourselves to base64 from the beginning. > > Sanjiva. --umit > > > >
Received on Wednesday, 19 October 2005 20:45:25 UTC