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 10:03:54 -0800
Message-Id: <7600710C-7386-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>


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
Received on Thursday, 11 March 2004 13:04:05 UTC

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