- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 22 Mar 2004 15:43:51 -0800
- To: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Cc: Mark Nottingham <mark.nottingham@bea.com>, public-ws-media-types@w3.org, Martin Gudgin <mgudgin@microsoft.com>
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 >> >
Received on Monday, 22 March 2004 18:44:51 UTC