This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Right now the GetMetadata operation leaves it up to the service to decide which of the three possible forms (EPR, URI or the data itself) is returned for each Dialect requested. This is problematic because there may be times when the client needs a particular format to complete its work. For example, if the client wants to update the metadata (using Transfer.Put) then it needs an EPR to the Metadata Resource. But there is no way for the client to demand that the GetMetadata operation return an EPR at all. Proposal: Add a new optional element to the GetMetadata request that specifies the formats requested: <mex:GetMetadata ?> (<mex:Dialect>xs:anyURI</mex:Dialect> (<mex:Identifier>xs:anyURI</mex:Identifier>)? (<mex:Format>xs:anyURI</mex:Format>)* )? </mex:GetMetadata> When not present the default is as current defined - up to the service to decide which (and how many) to return. We then need to define 3 URIs for each of the formats - eg: http://.../mex/format/EPR http://.../mex/format/URI http://.../mex/format/metadata for completeness, we could also define the default one too: http://.../mex/format/any If the service is unable to return the requested format then it skips that requested format (ie. nothing is returned for that one dialect/format).
*** Bug 6419 has been marked as a duplicate of this bug. ***
From MEX interop event... Should there be a feature for requesters to query for a specific retrieval (such as HTTP Get, SOAP Get or inline) mechanism? Proposed Clarification: Retrieval mechanisms are at the discretion of the provider. Depending on a providers infrastructure, the provider may offer one or more mechanisms. That is, the provider may provide metadata resources over whatever protocols and bindings that the provider supports. A metadata resource is just another endpoint. If a requester would like to use a particular mechanism for communicating with a metadata resource, the requestor could use a discovery mechanism that would help the requestor to discover endpoints that support a specific protocol or binding. Such discovery mechanisms are outside the scope of the WS-MetadataExchange specification.
Edited from http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0040.html Per our talks yesterday.... here's the new pseudo schema: <mex:GetMetadata ?> (<mex:Dialect>xs:anyURI</mex:Dialect> (<mex:Identifier>xs:anyURI</mex:Identifier>)? )? (<mex:Content> xs:anyURI </mex:Content>)* </mex:GetMetadata> And the proposed set of changes are: - define the default, when the mex:Content element is missing, as 'any' - define a new URI for 'any' so people can be explicit if they want - define a new URI for 'all' - meaning send back all metadata that is allowed to be sent back - clarify that 'skip' means that if a service is unable to send back the requested content then no metadata section will be sent back for that content. When not present the default is as current defined - up to the service to decide which (and how many) to return. We then need to define 5 URIs for each of the formats - eg: http://.../mex/content/EPR http://.../mex/content/URI http://.../mex/content/metadata http://.../mex/content/any http://.../mex/content/all
Done