- 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