deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <>
Subject Re: Sketch of CIMI model layer
Date Thu, 03 Nov 2011 17:49:10 GMT
Perhaps we should discuss this in the CMWG.  I'm not sure we've ever 
really had an in-depth discussion on this topic with the entire team.
To me, given that JSON doesn't have an outermost wrapper telling people 
what kind of entity is being serialized I think having the classname 
someplace in the mime type is important.  Whether its: 
application/CIMI-Machine+json   or application/json;type=CIMI-Machine 
doesn't really matter much to me. 

STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |
The more I'm around some people, the more I like my dog.

David Lutterkort <> 
11/03/2011 01:04 PM

Doug Davis/Raleigh/IBM@IBMUS
Re: Sketch of CIMI model layer

On Thu, 2011-11-03 at 08:56 -0400, Tong Li wrote:
> In my previous implementation, request with body are always in xml 
> it was never in a HTML form post. The reason was that DMTF spec did not
> really care HTML. All forms of requests should be in theory the
> content-type of application/CIMI-<ResourceType>+xml or
> application/CIMI-<ResourceType>+json. When I implemented the client to
> produce the request, I did not add that header, because I was not sure 
> add that header will actually break Sinatra so it may not be able to
> determine if the request is actually for xml or json.

That's actually a very good point: these custom MIME types are a pain in
the neck. They break the default behavior of any
dispatch-by-content-type framework, and require some manual fiddling to
get it back on track.

In Deltacloud, we generate the response with the following (in Rails,
the code would look exactly the same):

        respond_to do |format|
          format.xml  { .. generate XML output .. }
          format.json { .. generate JSON output .. }

With the custom MIME types in the Accept header, the above doesn't work
out of the box - we painstakingly have to teach the framework that
application/CIMI-Foo+xml is really application/xml, and
application/CIMI-Foo+json is application/json.

The purported gain of being able to dispatch on/know what is being asked
for is not there. To me the whole thing is a little bit like replacing
image/png with image/passport-pic+png, image/soccer-team+png,
image/kittens-in-a-pile+png, etc.

If there ever is a need for the client to select the representation of a
resource by type, this can be done through media type parameters, i.e.
the client could send


But I don't really see a need for that - there is only ever one CIMI
Type that comes back from a request, and I don't believe that the
flexibility of choosing between types will really help implementors.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message