- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 10 Mar 2004 18:33:29 -0800
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>, mgudgin@microsoft.com
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 Wednesday, 10 March 2004 21:34:08 UTC