- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 10 Mar 2004 17:43:39 -0800
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>
It's probably safest to ask Gudge to characterise exactly what we need :) 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. 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 20:43:46 UTC