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:40:22 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1OCLXK-0008BC-Js@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700


Ram Jeyaraman <ram.jeyaraman@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ram.jeyaraman@microsoft.com




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

The WG discussed this and decided to close this issue with no action. 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 particular
content type. Thus, a profile could remove the use of Content attribute
allowing a service to return any content type by a client.  [1] “When not
present the default value is
"http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".

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:40:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 May 2010 23:40:27 GMT