W3C home > Mailing lists > Public > public-ws-media-types@w3.org > February 2004

Re: Draft Proposal for Assigning Media Types

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Mon, 09 Feb 2004 15:58:15 -0800
Message-ID: <40281E97.5040702@oracle.com>
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: public-ws-media-types@w3.org

Mark Nottingham wrote:

> Umit,
> Thanks for the proposal. A few comments;

Hi Mark,

I am glad that finally we are moving on. ;-) Thanks for your comments.

> * It seems like there's a lot of SOAP/WSDL/MTOM-specific language and 
> rationale in this draft. Although I understand this work is motivated 
> by Web services, it's critical that any mechanism like this gets the 
> broadest possible adoption, so that Web services stacks can leverage 
> this information in any XML it comes across, not just those that have 
> been born (and will die) in a controlled SOAP message exchange. 

That is an interesting point. The note only addresses the declaration of 
the expected and actual media-type in the schema and since there is no 
established support for media types in the schema. The motivation, 
however, is definitely coming from Web Services angle, wouldn't you 
agree?  We are jointly working towards publishing this note as WSD and 
XMLP wgs. Hence, I see that it is only natural that we indicate why we 
decided to do this and use our starting points as references. If you 
would like to suggest additional points to be added, would you please 
send them.

> * Some rationale needs to be given as to why only media types, instead 
> of content types, are addressed.
> * The document refers to problems with using URIs in the content of 
> the mediaType attribute. What are they? 

I did not want to repeat the discussions that have occured in XMLP 
meetings. It appears that it would be useful to repeat the discussion in 
the document as well. I will do that.

> * The acceptableMediaTypes attribute effectively defines a protocol. 
> This seems very application-specific, hides a lot of information in 
> ways that isn't accessible to XML tools, and reproduces a number of 
> problems that are already evident in HTTP content negotiation. Why is 
> it necessary to define this mechanism at all, when it's just as viable 
> to use Schema to constrain what values are acceptable (for example)? 

I am not sure I understand what you are proposing as an alternate approach.

We simply have two problems at hand.

(1) declaring the possible range of values that binary data may have 
(that is known) when schema is created. (image/*)
(2) declaration of the actual media type that is specified by the 
document. (image/jpeg)

For (1), we have discussed several ways of capturing this information 
in  the WSDL wg, namely declaring the same information via Schema 
annotations , Schema notations, as well as replicating the possible 
range of values with additional types that mimic the media type hierarchy.

After discussing the possibilities at our f2f meetings, an attribute 
indicating the range of possible values for a media-type appeared to be 
the simplest way of doing so [1]. Note the current proposal is 
equivalent to using Schema Annotations. The attribute value could  be 
also incorporated within an appinfo element and for all technical 
purposes, IMO, it is equivalent to the proposal we circulated.

Are you suggesting that we should utilize Schema Annotations instead or 
are you suggesting another way of accomplishing the same thing? If you 
are suggesting that we constrain the  range of values that are possible 
to declare an media type, lets discuss what the acceptable set should be 
to avoid the content negotiation problems that you are referring to. We 
were aware that this is rather a liberal set.

> * Section four appears to define a new type of Information Item. Is 
> this really necessary? Indeed, why is this section necessary at all?

This is to accomplish (2), namely the document needs to indicate the 
"actual" media-type of the binary data. Again, it is by using an 
additional attribute that the "binary" element would carry and indicate 
the media-type of the element in the document. I don't think that we can 
get away by not doing this, namely declare only (1) the range of 
expected media types but not say anything about the actual (concrete) 
media type  in the document itself. The document is always required to 
indicate its "concrete" media type, otherwise media-type declared in (1) 
such as (*/*) would allow any content to appear and would not be very 
useful for interpreting the media type.

Therefore, I would appreciate if you could clarify why you review this 
section to be redundant. If it is the spec language used that may be 
confusing, lets discuss.

> Cheers,



[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0218.html

> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems

Umit Yalcinalp                                  
Consulting Member of Technical Staff
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Monday, 9 February 2004 18:58:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:14 UTC