Re: Draft Proposal for Assigning Media Types

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