- From: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Date: Mon, 16 Feb 2009 14:26:40 -0800
- To: Doug Davis <dug@us.ibm.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
- Message-ID: <5AAAA6322448AA41840FC4563A30D6E84399953AC7@NA-EXMSG-C122.redmond.corp.microsoft>
Hi Doug, Our intent is slightly different here. We would prefer that returning metadata associated with the dialect: [Body]/mex:GetMetadata/mex:Dialect=http://www.w3.org/2009/02/ws-mex remain consistent and ONLY ever return metadata associated with dialects defined in the MEX specification. The changes we suggest would only apply to the default case where no dialect is specified. In this case it would normally return the same as above, unless it has been redefined by a profile to return something else, including Profile specific metadata dialects. Does that makes sense? --Geoff From: Doug Davis [mailto:dug@us.ibm.com] Sent: Tuesday, February 10, 2009 11:48 AM To: Geoff Bullen Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org Subject: RE: Issue 6404 - proposal Geoff, Actually, the "default value" doesn't change - its the meaning of the MEX dialect, no? So, we really should be tweaking the other paragraph - the one starting with "barring...". And doesn't that cover the possibility of someone else further constraining it? thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com Geoff Bullen <Geoff.Bullen@microsoft.com> Sent by: public-ws-resource-access-request@w3.org 02/10/2009 02:41 PM To Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> cc Subject RE: Issue 6404 - proposal Doug, It does not appear that the wording: "When this element is not present, the implied value is the MEX dialect." correctly expresses the sentiment that we agreed too earlier. Can we suggest using something more like: "When this element is not present, the implied value is the MEX dialect. However, the actual value may be defined by communities within the context of particular application domains and could include application specific metadata." --Geoff From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis Sent: Sunday, February 08, 2009 5:49 PM To: public-ws-resource-access@w3.org Subject: Re: Issue 6404 - proposal Resending since the html doesn't show up in the archives. thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com __________________ With no more chatter on this one... here's my proposal: Define the absence of a Dialect to mean the MEX dialect - something like: [Body]/mex:GetMetadata/mex:Dialect When this element is present, the response MUST include only Metadata Sections with the indicated dialect; 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 implied value is the MEX dialect. <delete> there is no implied value and so the response may include Metadata Sections with any dialect. </delete> And define the MEX dialect - add the following after the above text: [Body]/mex:GetMetadata/mex:Dialect="http://www.w3.org/2009/02/ws-mex" Barring some additional constraints, not defined by this specification, specifying the MEX dialect in a GetMetadata request message means that the service SHOULD return all available metadata formats that this client is allowed to retrieve. thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com Doug Davis/Raleigh/IBM@IBMUS Sent by: public-ws-resource-access-request@w3.org 01/29/2009 10:11 PM To Geoff Bullen <Geoff.Bullen@microsoft.com> cc "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, public-ws-resource-access-request@w3.org Subject Re: Issue 6404 - use of "whatever" Along those line, it would seem that saying something like "barring some negotiation, the absence of a Dialect value is equivalent tousing the MEX dialect". Gives the freedom for someone to profile it later - but otherwise we make sure "null" is well defined. thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com Geoff Bullen <Geoff.Bullen@microsoft.com> Sent by: public-ws-resource-access-request@w3.org 01/29/2009 09:06 PM To "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> cc Subject Issue 6404 - use of "whatever" This issue is about defining the MEX dialect and defining what gets returned. http://www.w3.org/Bugs/Public/show_bug.cgi?id=6404 In particular, I was asked to provide an example of why it might be useful, in the case where no dialect is specified in the GetMetadata request, for the service itself to be able to decide what it would return (the so-called "whatever" case). The other option would be for this case to return all MEX sections. The best example I can provide for the "whatever" case is this: If the MEX specification gets "profiled" for a specific purpose, it would be very useful to allow the profile to be able to specify what metadata is to be returned in this default case (especially the non-MEX defined metadata sections). If you do not do this then each profile would have to define some separate dialect to mean "give me all the metadata within my profile". Thus the default case gives you an over-loadable definition of "all" or perhaps "normal", which can include non-MEX defined sections. In a typical profiled case: Nothing = "return all metadata within my profile" MEX = "return all MEX dialects" If it is not a profiled implementation, the spec could be recommend that the implementation return: Nothing = MEX = "return all MEX dialects"
Received on Monday, 16 February 2009 22:27:24 UTC