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

[Bug 9700] Mex: Introduce a mechanism allowing the service not to return the metadata in the requested content format, while indicating that other formats are available

From: <bugzilla@jessica.w3.org>
Date: Wed, 12 May 2010 23:45:13 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1OCLc1-0008GF-Og@jessica.w3.org>

--- Comment #2 from Ram Jeyaraman <ram.jeyaraman@microsoft.com>  2010-05-12 23:45:13 ---
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.

This is because 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
content type. Thus, a profile could remove the use of Content attribute by a
client allowing a service to return any content type.  [1] “When not present
the default value is

Further, if the client wants a particular content type or format, it can
request that by specifying that in the GetMetadata request.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
Received on Wednesday, 12 May 2010 23:45:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:38 UTC