- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 May 2010 20:26:24 +0000
- To: public-ws-resource-access-notifications@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700 Summary: Introduce a mechanism allowing the service not to return the metadata in the requested content format, while indicating that other formats are available Product: WS-Resource Access Version: LC Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: MetadataExchange AssignedTo: public-ws-resource-access-notifications@w3.org ReportedBy: antoine.mensch@odonata.fr QAContact: public-ws-resource-access-notifications@w3.org 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). -- 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 Monday, 10 May 2010 20:26:25 UTC