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/>
http://www.w3.org/TR/2004/WD-xml-media-types-20041102/
[2]
<http://lists.w3.org/Archives/Public/public-ws-media-types/2004Nov/0006.html
>
http://lists.w3.org/Archives/Public/public-ws-media-types/2004Nov/0006.html
[3]
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html
#x268>
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html#
x268
[4]
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-type
s.html>
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-types
.html