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

[Bug 9700] New: 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: Mon, 10 May 2010 20:26:24 +0000
To: public-ws-resource-access-notifications@w3.org
Message-ID: <bug-9700-2780@http.www.w3.org/Bugs/Public/>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 May 2010 20:26:28 GMT