W3C home > Mailing lists > Public > public-ws-media-types@w3.org > March 2005

WSD Issue 268 Closed

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

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday, 16 March 2005 19:23:11 GMT