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

Re: Draft Proposal for Assigning Media Types

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 10 Mar 2004 16:22:40 -0800
Message-Id: <350847DC-72F2-11D8-8EB5-000A95BD86C0@bea.com>
Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>

Based on our discussion in Cannes, I'm not opposed to the outlined 
approach. However, I think we (WSDL and XMLP) should raise an issue 
with XML Schema regarding the ability to constrain an attribute in the 
manner we would have liked to.

regards,


On Feb 10, 2004, at 11:39 PM, Anish Karmarkar wrote:

> 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
>>>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Wednesday, 10 March 2004 19:22:46 UTC

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