- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Tue, 30 Mar 2004 17:26:12 -0800
- To: Mark Nottingham <mark.nottingham@bea.com>
- Cc: public-ws-media-types@w3.org, Umit Yalcinalp <umit.yalcinalp@oracle.com>, Martin Gudgin <mgudgin@microsoft.com>
Mark Nottingham wrote: > That's an issue, not a requirement. The question I was trying to get to > was whether we need to allow open-ended sets (like image/*) > specifically, or just closed sets. I do wonder whether the ability to > say "I'd like an image; don't care what format you use, even if I've > never heard of it" is useful in a Web services context. > The use case I had in mind was to allow all the image formats that are well-know, standard and well-supported. If an unknown format is sent this would result in some sort of app level fault. Another alternative is to enumerate the various formats that are supported. E.g., "image/jpeg image/png ..." > Once we go beyond restricting the content of the attribute and talk > about the content itself as having properties (such as media type), we > stumble into full content negotiation (e.g., CC/PP, conneg, etc), which > is very much out of scope for both WGs. If we want to bring it in-scope, > we should leverage external work that's been going on for nearly a > decade, rather than trying to reinvent it in a TF with four participants. > All I am looking for really is a way to declaratively say that attribute "mediaType" can have a value from amongst a set of values (and we can discuss whether that should be "type/*" or enumeration of all accepted values or both). The only way I can do this is without using schema extensibility points is by defining my own attribute in my namespace. Unfortunately, having everyone define their own attributes does not provide any interop. > Unless we have concrete use cases that absolutely require this kind of > negotiation, I believe it would be more prudent to stick with a limited > facility like Gudge outlined, if at all possible. > I do have a concrete usecase -- image/* If you look at WSDL 1.1 MIME binding [1] it is extremely useful to have a mime:content element with a type attribute with a value of 'image/*' or have two mime:content elements as children of the same mime:part with type attribute with a values of 'image/gif' and 'image/png' respectively (specifying alternate media-types). One of the short-coming of WSDL 1.1 MIME binding is that it provides this information only at the WSDL message part levels. So if one has binary data that is 'embedded' inside a part there is no way to describe the media type of this embedded binary data. XML schema is the logical choice, but if we don't allow users to specify a list of media-types (or '*') the description abilities will be severely hampered. -Anish -- [1] http://www.w3.org/TR/wsdl.html#_Toc492291084 -Anish -- > > On Mar 22, 2004, at 3:43 PM, Anish Karmarkar wrote: > >> I had assumed that allowing something like 'image/*' was a >> requirement. See XMLP issue 443 [1] (3rd bullet item). >> >> -Anish >> -- >> >> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x443 >> >> >> Umit Yalcinalp wrote: >> >>> Mark Nottingham wrote: >>> >>>> Do we have use cases where wildcarding is required? It makes sense >>>> in some MIME and HTTP situations, but I'm not so sure about Web >>>> services. >>> >>> I think it is similar to HTTP/MIME. Think about image/*. At the time >>> of when you construct a schema, not knowing the specific type but >>> knowing that a binary element represents an image is a reasonable >>> thing to do. Sending gif or jpeg attachment and indicating the actual >>> type in the document is very common use case. Further, it seems to me >>> that there is a well established usage pattern due to HTTP/MIME that >>> we would be very restrictive if we were to not to allow wildcards. >>> --umit >>> >>>> >>>> >>>> >>>> On Mar 17, 2004, at 3:10 PM, Umit Yalcinalp wrote: >>>> >>>>> Ok, maybe I did not grasp exactly what you are getting at. >>>>> >>>>> Are you trying to combine the two distinct cases of declaring the >>>>> actual media type and the accepted media type into one attribute? >>>>> >>>>> As far as I see, and as you point out, dealing with wildcards is a >>>>> real problem (image/*) because the value space for the attribute >>>>> when declared and when used is going to be different. This is why >>>>> in our original proposal, we defined two distinct attributes, one >>>>> for the schema and one for the document. I am not sure whether we >>>>> can combine these two distinct requirements into one easily because >>>>> of reconciling the wildcards via the schema. As a matter of fact, >>>>> we discussed this in detail during one of the WSDL f2f meetings, >>>>> and could not find a good solution, hence the current proposal. >>>>> >>>>> Just to clarify, I am not married to with having two attributes >>>>> ;-). I just can not see a solution with a single attribute without >>>>> the wildcard problem. >>>>> >>>>> --umit >>>>> >>>>> >>>>> Martin Gudgin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Mark Nottingham [mailto:mark.nottingham@bea.com] >>>>> Sent: 11 March 2004 17:26 >>>>> To: Martin Gudgin >>>>> Cc: Anish Karmarkar; public-ws-media-types@w3.org; Umit Yalcinalp >>>>> Subject: Re: Draft Proposal for Assigning Media Types >>>>> >>>>> So it looks like we're back to square one. >>>>> >>>>> Not quite! After sleeping on this ( for about a week ;-) ) I awoke >>>>> this >>>>> morning with a solution; Fixed values! Here is an example schema. >>>>> >>>>> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' >>>>> targetNamespace='http://www.w3.org/2004/03/MediaTypes' >>>>> xmlns:tns='http://www.w3.org/2004/03/MediaTypes' > >>>>> <xs:attribute name='MediaType' type='tns:MediaType' /> >>>>> <xs:simpleType name='MediaType' > >>>>> <xs:restriction base='xs:string' > >>>>> <xs:pattern value='{pattern for media types goes here}' /> >>>>> </xs:restriction> >>>>> </xs:simpleType> >>>>> </xs:schema> >>>>> >>>>> >>>>> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' >>>>> targetNamespace='http://example.org/myservice' >>>>> xmlns:tns='http://example.org/myservice' >>>>> xmlns:mt='http://www.w3.org/2004/03/MediaTypes' > >>>>> >>>>> <xs:import namespace='http://www.w3.org/2004/03/MediaTypes' /> >>>>> >>>>> <xs:element name='Person' type='tns:Person' /> >>>>> <xs:complexType name='Person' > >>>>> <xs:sequence> >>>>> <xs:element name='Name' type='xs:string' /> >>>>> <xs:element name='Portrait' type='tns:Portrait' /> >>>>> <xs:element name='Signature' type='tns:Signature' /> >>>>> </xs:sequence> >>>>> </xs:complexType> >>>>> >>>>> <xs:complexType name='Portrait' > >>>>> <xs:simpleContent> >>>>> <xs:extension base='xs:base64Binary' > >>>>> <xs:attribute ref='mt:MediaType' fixed='image/jpeg' >>>>> required='true' >>>>> /> >>>>> </xs:extension> >>>>> </xs:simpleContent> >>>>> </xs:complexType> >>>>> >>>>> <xs:complexType name='Signature' > >>>>> <xs:simpleContent> >>>>> <xs:extension base='xs:base64Binary' > >>>>> <xs:attribute ref='mt:MediaType' >>>>> fixed='application/pkcs7-signature' required='true' /> >>>>> </xs:extension> >>>>> </xs:simpleContent> >>>>> </xs:complexType> >>>>> >>>>> </xs:schema> >>>>> >>>>> >>>>> The required='true' just mandates that the attribute has to appear in >>>>> the instance and does not affect the workings of the proposal. >>>>> >>>>> The only problem I can see with this is that you can't say image/*. >>>>> >>>>> Thoughts? >>>>> >>>>> Gudge >>>>> >>>>> >>>>> Are we agreed that we should say something to Schema about this? >>>>> >>>>> >>>>> On Mar 11, 2004, at 5:08 PM, Martin Gudgin wrote: >>>>> >>>>> >>>>> >>>>> -----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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Mark Nottingham Principal Technologist >>>> Office of the CTO BEA Systems >>>> >>>> > > -- > Mark Nottingham Principal Technologist > Office of the CTO BEA Systems >
Received on Tuesday, 30 March 2004 20:27:10 UTC