Re: Draft Proposal for Assigning Media Types

Mark Nottingham wrote:
> 
> 
> On Mar 30, 2004, at 5:26 PM, Anish Karmarkar wrote:
> 
>> Mark Nottingham wrote:
>>
>>> That's an issue, not a requirement. The question I was trying to get 
>>> to was whether we need to allow open-ended sets (like image/*) 
>>> specifically, or just closed sets. I do wonder whether the ability to 
>>> say "I'd like an image; don't care what format you use, even if I've 
>>> never heard of it" is useful in a Web services context.
>>
>>
>> The use case I had in mind was to allow all the image formats that are 
>> well-know, standard and well-supported. If an unknown format is sent 
>> this would result in some sort of app level fault. Another alternative 
>> is to enumerate the various formats that are supported. E.g., 
>> "image/jpeg image/png ..."
> 
> 
> If enumeration is good enough, can't we tell people to define their own 
> schema for a well-known attribute, as Gudge outlined? IIRC lack of 
> support for /* was the only downside of that approach.
> 

No, the proposal has two downsides: you cannot have /* or enumeration of 
  types such as "image/jpeg image/png".

Thinking about this more, there is yet another solution:
instead of defining a "standard" attribute for indicating media types, 
we could define a schema type in the media-type namespace and 
applications can sub-type this type and define/use an attribute of that 
type. Processors can then key-off the type (instead of the attribute 
name). This is certainly doable, but I find the 2 attribute solution 
(that uses schema extensibility) to be much easier and simpler -- as 
processors can key-off the attribute-name.

-Anish
--