RE: Draft Proposal for Assigning Media Types

 

> -----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
> 
>

Received on Wednesday, 17 March 2004 16:23:49 UTC