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

Re: Draft Proposal for Assigning Media Types

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Thu, 11 Mar 2004 14:51:21 -0800
Message-ID: <4050ED69.3030900@oracle.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: Mark Nottingham <mark.nottingham@bea.com>, Martin Gudgin <mgudgin@microsoft.com>, public-ws-media-types@w3.org



Anish Karmarkar wrote:

>
> This approach does not work if I have two elements of type 
> base64Binary occurring in the same wsdl/schema and their media-types 
> are different. E.g., I have element A with media-type of image/jpeg 
> and another element B with media-type of application/octet-stream and 
> I want to indicate in the schema the media-type of each element.
>
> Given that both the elements will use the same MediaType attribute, I 
> cannot define/redefine the MediaType attribute to satisfy the mutually 
> exclusive media-types.
>
> May be I misunderstood the suggestion. 

That is what I understood as well. Gudge, could you clarify?

>
>
> I also don't like the idea of having everyone defining a schema for an 
> attribute in a namespace that is owned by someone else. Kinda goes 
> against accepted practices. 

>
>
> -Anish
> -- 
>
> Mark Nottingham wrote:
>
>>
>> On Mar 11, 2004, at 4:58 AM, Martin Gudgin wrote:
>>
>>> We could do it today, here's one option;
>>>
>>> 1.    Write a schema which defines xop:MediaType attribute as the open
>>> pattern for media types
>>>
>>> 2.    Write a second schema that redefines the type of xop:MediaType
>>> to be some restriction of the media type pattern, e,g, image/jpeg
>>>
>>> 3.    Ref xop:MediaType attribute in second schema from schema in
>>> WSDL.
>>
>>
>>
>> Doing it in regex? Oof.
>>
>>> Alternatively we could also just tell people to write a schema for the
>>> xop namespace that defines a MediaType attribute with the required
>>> values.
>>
>>
>>
>> So, we supply the name, the supply the substance? I could live with 
>> that. Umit, Anish?
>>
>>
>>> WSDL tools would process either of the above just fine.
>>>
>>> Gudge
>>>
>>>
>>>> -----Original Message-----
>>>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>>>> Sent: 11 March 2004 02:33
>>>> To: Mark Nottingham
>>>> Cc: public-ws-media-types@w3.org; Umit Yalcinalp; Martin Gudgin
>>>> Subject: Re: Draft Proposal for Assigning Media Types
>>>>
>>>> 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
>>>>>
>>>>
>>>>
>>
>> -- 
>> Mark Nottingham   Principal Technologist
>> Office of the CTO   BEA Systems
>>
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Thursday, 11 March 2004 17:52:02 UTC

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