- From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Date: Sun, 3 Jan 2010 18:01:24 +0000
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
I believe 8200 and 8297 addressed the main point of this issue by removing the ws-mex-all Dialect IRI. If that is true, this can be closed with no action.
-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Friday, November 13, 2009 6:52 PM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 8296] New: services can't know what metadata a consumer might need
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8296
Summary: services can't know what metadata a consumer might need
Product: WS-Resource Access
Version: PR
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: MetadataExchange
AssignedTo: public-ws-resource-access-notifications@w3.org
ReportedBy: gilbert.pilz@oracle.com
QAContact: public-ws-resource-access-notifications@w3.org
The description of [Body]/mex:GetMetadata/mex:Dialect has the following
sentence:
"When this element is not present, the endpoint SHOULD return all the types of metadata that it deems necessary to communicate with it."
The phrase "deems necessary" is problematic. Except for simple services, there are generally a number of ways to interact with any service. Metadata of different types and scopes may or may not be "necessary" depending upon how the consumer intends to interact with the service. How can the "endpoint" (more accurately "service instance") be expected to know how the consumer intends to interact with it and which metadata is or isn't "necessary"? For example, if WS-RM is optionally supported, is it "necessary" to return the WS-RM feature WSDL?
Proposal: "When this element is not present, the endpoint MUST return all available types of metadata".
--
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 Sunday, 3 January 2010 18:01:48 UTC