W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2005

RE: describing a service that returns an image/jpg (for example)

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Wed, 19 Oct 2005 13:46:11 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D6416556A236@uspale20.pal.sap.corp>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:37 GMT