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

Re: Draft Proposal for Assigning Media Types

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 10 Mar 2004 18:33:29 -0800
Message-ID: <404FCFF9.6060103@oracle.com>
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>, mgudgin@microsoft.com

Mark Nottingham wrote:

> It's probably safest to ask Gudge to characterise exactly what we need :)
> 

LOL.

I believe Gudge was talking about using substitution groups and 
concluded that one could not do that with attributes.

> All that I'm saying is that we had what seemed to be a reasonable 
> requirement that Schema couldn't fulfil. We should give that information 
> to the Schema WG as input to their process.
> 

+1

> Regards,
> 
> On Mar 10, 2004, at 5:36 PM, Anish Karmarkar wrote:
> 
>> Mark,
>>
>> Are you suggesting that we ask that XML schema support attribute 
>> substitution group?
>>
>> Even if there were a attribute substitution group, that would still be 
>> a problem because one of the goals was to have a "standard" attribute 
>> in a namespace that would indicate the media type of base64Binary data 
>> in a doc instance.
>>
>> -Anish
>> -- 
>>
>> Mark Nottingham wrote:
>>
>>> 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
>>>
> 
> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
> 
Received on Wednesday, 10 March 2004 21:34:08 UTC

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