- 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