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

Re: Draft Proposal for Assigning Media Types

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Thu, 08 Apr 2004 10:38:12 -0700
Message-ID: <40758E04.4040702@oracle.com>
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>, Martin Gudgin <mgudgin@microsoft.com>

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.

Received on Thursday, 8 April 2004 13:42:49 UTC

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