Re: Draft Proposal for Assigning Media Types

Umit Yalcinalp wrote:
 >
> 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.
> 

I think we need to achieve a careful balance here. It would be good to 
make the mechanism generic enough that non-Web services related XML 
technologies can leverage/utilize this if they chooses to do so. I think 
the proposal achieves that. It would be good to call that out. But I 
don't think we should go too far and say that this is *the* mechanism 
for representing media-types for all XML technologies (not sure if that 
is what you meant).

>>
>>
>> * Some rationale needs to be given as to why only media types, instead 
>> of content types, are addressed.
>>

I was going to send an email regarding this. I don't see why this should 
be restricted to media types only. I think we should allow 
content-types. The rationale for doing so is -- media types RFCs are 
allowed to specify mandatory parameters. Makes sense?

>> * 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,
> 
> 
> Thanks.
> 
> --umit
> 
> [1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0218.html
> 
>>
>> -- 
>> Mark Nottingham   Principal Technologist
>> Office of the CTO   BEA Systems
>>
>

Received on Wednesday, 11 February 2004 03:01:43 UTC