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

* Yalcinalp, Umit <umit.yalcinalp@sap.com> [2005-10-19 13:46-0700]
> > -----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.

So, to be clear, what you are proposing is the following:
- identify serialization formats with a media type token
- keep our 3 defined serializations:
  application/x-www-form-urlencoded, application/xml,
  multipart/form-data
- define a new style:
  http://www.w3.org/YYYY/MM/wsdl/style/base64-encoded
- say that any serialization format other than the 3 formats we
  defined are defined as a message reference pointing to one element
  of time xsd:base64 with an xmime:expectedContentType attribute, that
  the value of xmime:expectedContentType must match the serialization
  format name, and that this name is the content-type to use

I am afraid that it will make the use of other schema languages and
models other than the Infoset (e.g. RDF) useless for our HTTP binding
without a required extension.

For example, if I define an extension to use Relax NG as my schema
language, I will need to come up with a {rng http input serialization}
property overriding {http input serialization} to be able to serialize
the message as application/x-www-form-urlencoded in addition to the
serialization format itself. With my alternate proposal at [1], I
would just give a now URI for this application/x-www-form-urlencoded
serialization format.

Here's a comparison:

Sanjiva's option:

  <rng:support wsdl:required="true"/>

  <interface>
    <operation>
      <input rng:element="my:input"/>
      <output element="my:output"/>
    </operation>
  </interface>

  <binding>
    <operation whttp:method="GET"
    rng:inputSerialization="application/x-www-form-urlencoded"/>
  </binding>

Hugo's option:

  <interface>
    <operation>
      <input rng:element="my:input"/>
      <output element="my:output"/>
    </operation>
  </interface>

  <binding>
    <operation whttp:method="GET"
    whttp:inputSerialization="http://hh.example/http/rng/application/x-www-form-urlencoded"/>
  </binding>

Also, it is worth noting that, for DAWG, who wants to do something
like whttp:outputSerialization="application/xml, application/rdf+xml",
they will have an output message declaration as follows:

  <element name="sparql-results">
    <complexType>
      <choice>
	<element maxOccurs="1" ref="vbr:sparql"/>
	<element name="rdf:RDF" type="xsd:base64"
		 xmime:expectedContentType="application/rdf+xml"/>
      </sequence>
    </complexType>
  </element>

I don't think it's anything we can't describe with a style. However,
styles are at the operation level, so it may mean that we need a
http://www.w3.org/YYYY/MM/wsdl/style/base64-encoded-in and
http://www.w3.org/YYYY/MM/wsdl/style/base64-encoded-out to be able to
serialize those media types both in an HTTP request or response,
though we may want to constrain the input and care only about the
output.

I have to say that I prefer my solution: it's just proposing to change
the naming of the serialization formats, and we're done, without
restricting any of our functionality and forcing people to
Base64-encode data (or pretend to).

Cheers,

Hugo

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0028.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/