Re: Draft Proposal for Assigning Media Types

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