RE: Draft Proposal for Assigning Media Types

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.

Alternatively we could also just tell people to write a schema for the
xop namespace that defines a MediaType attribute with the required
values.

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

Received on Thursday, 11 March 2004 07:59:40 UTC