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

* Yalcinalp, Umit <> [2005-10-19 13:46-0700]
> > -----Original Message-----
> > From: 
> > [] 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,
- define a new style:
- 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"/>

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

    <operation whttp:method="GET"

Hugo's option:

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

    <operation whttp:method="GET"

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">
	<element maxOccurs="1" ref="vbr:sparql"/>
	<element name="rdf:RDF" type="xsd:base64"

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 and 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

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).



Hugo Haas - W3C -

Received on Thursday, 20 October 2005 13:42:07 UTC