W3C home > Mailing lists > Public > public-ws-resource-access-comments@w3.org > May 2010

WS-RA issue 9700 disposition

From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
Date: Wed, 12 May 2010 23:54:40 +0000
To: "Antoine Mensch [antoine.mensch@odonata.fr] (antoine.mensch@odonata.fr)" <antoine.mensch@odonata.fr>
CC: "public-ws-resource-access-comments@w3.org" <public-ws-resource-access-comments@w3.org>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <503546C5699C1144BDEA0D0DFFE7F8812D0FDD06@TK5EX14MBXC110.redmond.corp.microsoft.com>
Hi Antoine,

Thanks for submitting the issue. The WG discussed this and decided to close this issue with no action.

The compliance section of every specification states that an optional element of a request MUST be able to be handled by a server, unless the specification has specific text allowing it as a server option. Hence, the service is required to support the Content attribute.

The WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support a
particular content type. Thus, a profile could remove the use of Content attribute by a client allowing a service to return any content type.

Further, if the client wants a particular content type or format, it can request that by specifying that in the GetMetadata request.
Please let us know if you have any questions.

Thank you.

[1] "When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".
Received on Wednesday, 12 May 2010 23:55:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:40:12 UTC