Re: Action item: HTTP binding for accepts header and output Serialization.

As per the discussion on yesterday's call to revive the discussion
around Accept headers, here is the proposal I had sent to resolve:

| ?ED       2004-05-20: David Orchard to update HTTP binding to·
|                       include discussion of how to generate an·
|                       accepts header from schema annotations·
|                       conformant to the media types extension·
|                       document, and to use outputSerialization·
|                       based on that information.

My message is archived at:

    http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0005.html

* Hugo Haas <hugo@w3.org> [2004-07-01 10:26+0200]
[..]
> * David Orchard <dorchard@bea.com> [2004-06-23 17:54-0700]
[..]
> [..]
> > Insert new Section 3.6.4 Serialization as Other
> > 
> > This serialization format is designed to allow a Web service to send or receive binary data.  The instance data of the input or output is serialized according to the media type of the instance data.  The media type that is expected or allowed on input, and the media type that may or will be sent on output is specified according to the Assigning Media types to binary data in XML.  The sender may specify an HTTP Accept header using the Abstract Data feature.  The Accept header value should be within the set of values defined by the expected Media Type element value.
> 
> to which I replied that I didn't think that the Application Data
> Feature should be used for this on the sender side as I think that
> Accept is just a facet of HTTP which is basically set in an
> implementation-specific manner. To me, it's basically like
> Content-Length or other headers of this class.
> 
> Therefore, I was proposing that we just say that we say two things:
> 
> * Hugo Haas <hugo@w3.org> [2004-06-25 17:40+0200]
> [..]
> > - expectedMediaType placed on an input message is equivalent to an
> >   Accept header from the POV of the service.
> 
> i.e. it hints the sender of the message about what media types the
> receiver supports.
> 
> This would be added to the media type Note.
> 
> > - an HTTP request from a requester agent may always contain an Accept
> >   header; the value of the header should take into account the
> >   expectedMediaType information for subsequent output messages from
> >   the provider agent to make sense.
> 
> When I said that "value of the header should take into account the
> expectedMediaType information for subsequent output messages", I meant
> that if the output message has expectedMediaType="image/png image/gif"
> and my implementation supports JPEG and PNG, there's not point in
> saying that I accept JPEGs as the service only offers PNG or GIF. This
> basically is an optimization which is pointed out which may be left
> out if it's too obscure.
> 
> This would be added to the HTTP binding in Part 3.
> 
> Therefore, to answer your initial question with a straight answer, my
> email was a proposal to address the AI by merely adding 2 explanation
> sentences to the document.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/