- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 16 Mar 2005 20:22:23 +0100
- To: <LMM@acm.org>
- Cc: <www-ws-desc@w3.org>, <public-ws-media-types@w3.org>
- Message-ID: <99CA63DD941EDC4EBA897048D9B0061D12292217@uspalx20a.pal.sap.corp>
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 Wednesday, 16 March 2005 19:23:11 UTC