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

* Jonathan Marsh <jmarsh@microsoft.com> [2004-06-30 11:47-0700]
> I'm not sure where this is going.  Sounds like there are more issues
> that we need to discuss prior to resolving this editorial AI?  Or is
> this a proposal for additional functionality?

Let me try and recap. Dave proposed to address his action item by
saying that a service requester can use the Application Data Feature
to specify an Accept header:

* David Orchard <dorchard@bea.com> [2004-06-23 17:54-0700]
> ?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.
[..]
> 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/