- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 10 Mar 2004 17:36:28 -0800
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>
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 >
Received on Wednesday, 10 March 2004 20:37:09 UTC