This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

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
Summary: Mex: Introduce a mechanism allowing the service not to return the metadata in...
Status: CLOSED WONTFIX
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: MetadataExchange (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: notifications mailing list for WS Resource Access
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: externalComments, reviewerSatisfied
Depends on:
Blocks:
 
Reported: 2010-05-10 20:26 UTC by Antoine Mensch
Modified: 2010-06-01 14:08 UTC (History)
1 user (show)

See Also:


Attachments

Description Antoine Mensch 2010-05-10 20:26:24 UTC
Supporting metadata representation in various formats (Content attribute of GetMetadata) may be a burden for embedded devices. Therefore, a future version of DPWS (OASIS Devices Profile for Web Services) may decide to profile the GetMetadata operation to let the server decide in which format the metadata is returned (basically ignoring the Content attribute, which is the behavior in the Submission version of the spec). However, this means that GetMetadata requests containing unsupported format specifications will either return no metadata section for the specific metadata or fault, using a DPWS-specific fault. In both cases, the approach will not allow a standard WS-Mex client to know for sure that the metadata is available in another format (and that it can be obtained by sending a new request with different parameters). A standard WS-Mex fault, or a placeholder in the response indicating that the Content attribute or the requested format is not supported could be introduced instead. Such mechanism could even indicate to the client which content formats are available.
Looking at the WS-Mex metadata before actually performing the request could be an alternative, however as noted in the spec there is a bootstrap problem, which means that many clients are likely to try their luck without looking first at the metadata (which is optional anyway).
Comment 1 Ram Jeyaraman 2010-05-12 23:40:22 UTC
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.
Comment 2 Ram Jeyaraman 2010-05-12 23:45:13 UTC
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 particular
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
"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.
Comment 3 Robert Freund 2010-05-14 13:17:49 UTC
reviewer satisfied (sort of) http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0048.html