Re: Draft Proposal for Assigning Media Types

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