RE: issue 8200: new proposal

We also need to mention that when the "ws-mex-all" Dialect URI is used in a GetMetadata request, the Identifier and Content attributes MUST be absent.

Thinking a bit more about this, why not just entirely delete the "ws-mex-all" Dialect URI, since the absence of a Dialect in a request already implies retrieving all [1] metadata?

Thanks.

[1]

[Body]/mex:GetMetadata/mex:Dialect
When this repeating OPTIONAL element is present, the response MUST include only Metadata Sections corresponding to the Dialect specified by the IRI attribute; if the receiver does not have any Metadata Sections of the indicated Dialect, the response MUST include zero Metadata Sections.
When this element is not present, the endpoint SHOULD return all the types of metadata that it deems necessary to communicate with it.
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, December 08, 2009 9:33 PM
To: public-ws-resource-access@w3.org
Subject: issue 8200: new proposal


Per my AI, here's an amended proposal for 8200:
- remove the "...-mex-all" Dialect URI from the Identifier table and the Metadata Format table
- for the definition of the ..-mex-all dialect, replace:
This value returns all known metadata. The endpoint has the option to optimize the format in which it returns the data.
with:
This special dialect IRI indicates that all known metadata dialects are to be returned.  This Dialect IRI is meant to only be used in GetMetadata request messages, not as a Dialect IRI in a mex:MetadataSection element, as there is no actual metadata format associated with it.  The endpoint has the option to optimize the format in which it returns the data.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.

Received on Wednesday, 9 December 2009 23:22:04 UTC