Re: Draft Proposal for Assigning Media Types

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.

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
>

Received on Thursday, 11 March 2004 17:23:08 UTC