RE: Draft Proposal for Assigning Media Types

 

> -----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
> 
> 
> 
>

Received on Thursday, 11 March 2004 20:09:05 UTC