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: Thu, 11 Mar 2004 17:26:29 -0800
Message-Id: <49DF6A2D-73C4-11D8-8EB5-000A95BD86C0@bea.com>
Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <public-ws-media-types@w3.org>, "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
To: "Martin Gudgin" <mgudgin@microsoft.com>

So it looks like we're back to square one.

Are we agreed that we should say something to Schema about this?


On Mar 11, 2004, at 5:08 PM, Martin Gudgin wrote:

>
>
>> -----Original Message-----
>> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
>> Sent: 11 March 2004 22:51
>> To: Anish Karmarkar
>> Cc: Mark Nottingham; Martin Gudgin; public-ws-media-types@w3.org
>> Subject: Re: Draft Proposal for Assigning Media Types
>>
>>
>>
>> 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?
>
> No, you're correct. I only realised this limitation after I'd sent my
> previous mail and hadn't had chance to point it out myself.
>
> :-(
>
> Gudge
>
>>
>>>
>>>
>>> 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
>>
>>
>>
>>
>>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Thursday, 11 March 2004 20:26:38 UTC

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