- From: Tom Jordahl <tomj@macromedia.com>
- Date: Thu, 17 Mar 2005 11:09:14 -0500
- To: "Larry Masinter" <LMM@acm.org>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: <www-ws-desc@w3.org>, <public-ws-media-types@w3.org>
- Message-ID: <39A72E1EBF03EB44AACFD8036D1489F9120895@p02exm01.macromedia.com>
+1 Sounds like good improvements -- Tom Jordahl Macromedia Server Development ________________________________ From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Larry Masinter Sent: Wednesday, March 16, 2005 3:34 PM To: 'Yalcinalp, Umit' Cc: www-ws-desc@w3.org; public-ws-media-types@w3.org Subject: RE: WSD Issue 268 Closed The fact that this is not a "recommendation" doesn't absolve you from the responsibility of giving good advice, so I find the reasoning that the document status being a Note means you don't have to pay attention to comments somewhat specious. "Users of this attribute information item are urged to use wild cards (for example, "image/*") with care ..." makes it sound like users are urged to use wild cards. I suggest changing the sense, at least: "Users of this attribute information item are urged to avoid using wild cards (for example, "image/*") ..." Similarly "If the set of expected media types are known, a list of media types is RECOMMENDED instead of wild cards..." makes it sound like the use of wild cards might be recommended if the set of expected media types is NOT known. Instead, I would recommend not using xmime:expectedContentTypes at all if the set of expected content types is not known. Larry ________________________________ From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] Sent: Wednesday, March 16, 2005 11:22 AM To: LMM@acm.org Cc: www-ws-desc@w3.org; public-ws-media-types@w3.org Subject: WSD Issue 268 Closed Larry, You raised an issue against the "Assigning Media Types to Binary Data in XML" Last Call WD [1] in your email at [2]. This was accepted by the WSD WG as issue 268 [3]. Here is our analysis and response to your issue: WSDL documents serve as a contract for describing the data, set of message exchanges and bindings that are needed to interact with the Web Service. The intent of the note [1] is not to redefine a content negotiation protocol, but to allow Web Services descriptions to declaratively state a set of media types that a service provider expects to understand. Although the definition of the expectedContentTypes is based on the definition of HTTP Accept header, its utility is declarative since it is provided within a service's description. It defines a static contract that is predefined with a WSDL document. Since the expectedContentTypes attribute and its content would be provided by the service provider, the value range would be a the set of values that the service provider could expect to process. A client would use the description to determine whether the media type declaration may be suitable for its needs. We also want to enable data binding tools to map existing known media types to known data types they can process. Hence, we expect that the expectedContentTypes values would not necessarily be wild card ranges in general. As a result, we considered, but decided not to restrict the values that expectedContentTypes attribute may contain in order not to restrict a service's flexibility. However, we included a clarification and recommendation in Section 2.2 (last paragraph) order to clarify the intent and the use of expectedContentTypes attribute with a recommendation that the authors should use a list of known types instead of using wildcards. You point out two other RFC documents with the caveat that they are not widely deployed and their interoperability is limited. We wanted to use a facility which had at least a wide exposure where its limitations are, at least, better undersood. There is also existing machinery that can process contentType/expectedContentTypes values and content. Hence, we decided that service providers can evaluate how to use the declarative facility before they publish their services selectively. Please also note that we are publishing a w3c note, not a recommendation track document, as a joint deliverable of WSD and XMLP wgs to assist in augmenting WSDL descriptions. A note can easily be superseeded by others if need be. In addition, a note has a different status/maturity level than a REC. Therefore, we have decided to close Issue 268 with the changes to Section 2.2 as stated. Please see the current version in [4] for these changes. We hope this email and the changes we adopted address the issue that you raised to your satisfaction. Best Regards, --Umit Yalcinalp (on behalf of WSD WG) [1] http://www.w3.org/TR/2004/WD-xml-media-types-20041102/ [2] http://lists.w3.org/Archives/Public/public-ws-media-types/2004Nov/0006.h tml [3] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.h tml#x268 [4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t ypes.html
Received on Thursday, 17 March 2005 16:09:57 UTC