RE: WSD Issue 268 Closed



Sounds like good improvements

Tom Jordahl
Macromedia Server Development


From: [] On
Behalf Of Larry Masinter
Sent: Wednesday, March 16, 2005 3:34 PM
To: 'Yalcinalp, Umit'
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/*") ..."




"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.








	From: Yalcinalp, Umit [] 
	Sent: Wednesday, March 16, 2005 11:22 AM
	Subject: WSD Issue 268 Closed


	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

	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) 



Received on Thursday, 17 March 2005 16:09:57 UTC