Re: Draft Proposal for Assigning Media Types

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
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Wednesday, 17 March 2004 20:41:29 UTC