W3C home > Mailing lists > Public > public-ws-media-types@w3.org > March 2004

Re: Draft Proposal for Assigning Media Types

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 17 Mar 2004 16:07:24 -0800
Message-Id: <3BAAC677-7870-11D8-803C-000A95BD86C0@bea.com>
Cc: public-ws-media-types@w3.org, Martin Gudgin <mgudgin@microsoft.com>, Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: Umit Yalcinalp <umit.yalcinalp@oracle.com>

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.


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 Wednesday, 17 March 2004 19:07:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:14 UTC