New Issue (media-types) Optionality of contentType attribute


While we were adding a couple of new examples to the media-types note 
[1], we encountered the following issue.

Currently, we are saying that contentType attribute is optional. 
However, we don't have any guidelines as to when it can be completely 
omitted and when it must be present. It appears that more clarifications 
on this aspect is needed.

For example, if expectedMediaType="image/jpeg", meaning the value is 
static, does not include wildcards, one may presumably  omit the 
contentType attribute declaration as expected media type is fixed. 
However, if the expectedMediaType allows wildcards, one would expect the 
contentType attribute to be present.

The cases where the attributes can occur in the schema are as follows: 
(+) indicates it is present (-) indicates it is not present for the 
same  data.


+ expectedMediaType
- contentType

+ expectedMediaType
+ contentType

- expectedMediaType
+ contentType

(4) neither of them occur in the schema.

The cases (1) and (3) are particularly interesting and require a bit 
more clarification. Please note that the relationship between the actual 
content or the mismatch of attribute values are orthogonal issues that 
we have already resolved for (2).

There are couple of ways to tackle tightening of the spec on this issue:

-- We may require using contentType attribute when media types note is 
utilized. (A bit restrictive in my opinion). Does not allow (1)


-- We may require using the contentType attribute in conjunction with an 
expectedMediaType declaration that allows wildcards but allow it to be 
optional otherwise. Note that the contentType attribute can be used 
without the expectedMediaType attribute in conjunction with base64Binary 
or hexBinary data with this clarification, thus allowing (3). I think 
this requirement will cover the cases above.

If there are any other options, that will be good to get them on the 
table for f2f.




Umit Yalcinalp                                  
Consulting Member of Technical Staff
Phone: +1 650 607 6154                          

Received on Friday, 10 September 2004 23:55:37 UTC