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

Comparison of Approaches

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Mon, 19 Apr 2004 14:20:40 -0700
Message-ID: <408442A8.4050407@oracle.com>
To: public-ws-media-types@w3.org
All,

I have written a note that compares the attribute centric approaches 
discussed so far as a basis for discussion. I also added an example for 
the third approach we hinted at, but not necessarily defined in detail 
to clarify what it would be like.

Cheers,

--umit





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



There are three methodologies identified so far:

-- The proposal as presented in [1]. 

   Pros: 

   -- Handles subtypes, such as "image/*" also list of subtypes. 
   -- Attribute based, defines a special global attribute that designates
      the media-type. Therefore, it is easy to infer the additional
      information in the document.


   Cons: 
 
   -- The approach requires two different attributes, one in the
      document to designate the actual media-type value and one in the
      schema designated by annotation. The methodology of
      incorporating annotations by schema extensions may not be
      generally supported by processors.

-- Gudge's Proposal in [2]. 

   Pros: 

   -- Simple, requires one attribute instead of two. 
   -- Applications can fix the value of the attribute to designate specific 
   values, such as "image/jpeg". 

   Cons: 
   -- Applications can not declare subtypes for content. It is not possible to 
      designate a media type without designating a subtype, disallows 
      enumeration, wildcard. 

-- Type Extension Proposal: 

   This proposal is to define a base type, MediaType and all known
   media types, derived from it in the media types note's schema. The
   level of granularity only extends to the media type but not to tthe
   subtypes in a media type hierarchy.

   Applications can further use these types to designate specific
   media types, using the method used in [2] by fixing the value or
   directly using the types for wildcarding. Applications define their
   own attributes that use these defined types for designating the
   media type of the binary data.
   

   Pros: 

   -- Similar to [2], as applications will rely on a single attribute declaration.
   
   
   Cons: 
   -- Applications must designate the attribures themselves. There is 
      not a single global attribute that designates the media type. 
   -- All media types (not subtypes) must be designated by the note. 
   -- It is complicated to process media type information. 
      Each attribute that the application uses must be evaluated to 
      infer whether it derives from the media type to further interpret 
      the content appropriately. 


   Here is a variant of the example used in [2] that illustrates the
   third approach:

The Media Types 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:simpleType name='MediaType' >
  <xs:restriction base='xs:string' >
   <xs:pattern value='{pattern for media types goes here}' />
  </xs:restriction>
 </xs:simpleType>
</xs:schema>

<!--
  The schema defines a type which is known to derive from the 
  base type MediaType. 

  All known media types are represented, such as image, text, ... 
  in the schema, but NOT the subtypes. 
-->
 
<xs:simpleType name='ImageType' >
  <xs:restriction base='tns:MediaType' >
   <xs:pattern value='image/{pattern for media types goes here}' />
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name='TextType' >
  <xs:restriction base='tns:MediaType' >
   <xs:pattern value='text/{pattern for media types goes here}' />
  </xs:restriction>
</xs:simpleType>

...


</xs:schema>


Schema For the Document: 


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

  <!-- The application defines its own attributes -->

  <xs:attribute name='ImageAttr' type='tns:ImageType' />
  <xs:attribute name='AppAttr' type='tns:ApplicationType' />

  <!-- The types are used to designate the media type -->

  <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='tns:ImageAttr' required='true'/>
    </xs:extension>
   </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name='Signature' >
   <xs:simpleContent>
    <xs:extension base='xs:base64Binary' >
     <xs:attribute ref='tns:AppAttr' 
                   fixed='application/pkcs7-signature' 
                   required='true' />
    </xs:extension>
   </xs:simpleContent>
  </xs:complexType>

</xs:schema>


References: 

[1]http://lists.w3.org/Archives/Public/public-ws-media-types/2004Apr/0000.html
[2]http://lists.w3.org/Archives/Public/public-ws-media-types/2004Mar/0010.html
Received on Monday, 19 April 2004 17:21:21 UTC

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