[occi-wg] Votes: XML vs. JSON vs. TXT

[CEW]

Gee I hope we aren't going down the RESTful path...that would be a waste 
for those of us that don't want that approach.

Chas.

Marc-Elian Bégin wrote:
> Correct me if I'm wrong but I understand that the service we're  
> considering here is a RESTFul web-service, and further following a  
> resource oriented architecture (see Ruby and Richardson's RESTFul Web  
> Services book).
>
> In any generic RPC protocol, you need to define verbs and messages  
> (methods and parameters).  With RESTFul and ROA, since we're  
> manipulating resources, the HTTP verbs (GET, PUT, POST, DELETE, etc)  
> provide a pretty clear semantic.  So what's left is the messages that  
> are exchanged between the client and the server.
>
> Another observation is that, and this is based on my personal  
> experience so feel free to contradict me, with 'big web-services' à la  
> SOAP, the only way to reach interoperability between SOAP (and WSDL)  
> tooling is to keep thing really simple (and stay away from the WS-*  
> stuff as much as possible).  And even armed with amazingly advanced  
> tooling, the in order to reach interoperability, the messages  
> (parameters) have to be simple... otherwise the cost of  
> interoperability goes up... and fast.
>
> So we need to keep the messages simple.
>
> As a user of the service, I want to be able to paste in my browser the  
> url to a resource and get something I understand, which means (X)HTML,  
> with the right hyperlinks to the resource's neighbours and possible  
> actions I can perform on these resources... right there in my  
> browser!  But if I'm a javascript, I probably want JSON or text.  And  
> if I'm Excel, I probably want CSV or text.  And if I'm Python or Java,  
> XML works.  And if I don't like any of these, I grab the XML and  
> transform it on the fly into something I like.
>
> I know, we're not in a design room in front of a white board... we're  
> trying to define a standard, but I think it's important to set the  
> scene in terms of implementation so that we know more or less what the  
> real thing's going to look like.
>
> Getting back to your question... I think that to be successful, OCCI  
> Web Services will have to embrace the reality of today's web, which is  
> to support a number of content-types.  And while I do realise that  
> from a standardisation point-of-view I'm suggesting to raise the bar a  
> little for v1.0, I don't think it's a problem.  And the reason for  
> that is 'simplicity'.  So if we're finding that our life becomes  
> difficult in specifying the messages in XML, JSON and TEXT, then we  
> might want to re-evaluate our complexity level.
>
> Having said all that, we can start with one language and add others as  
> we go along.  But then the choice become which one's first.  The  
> argument against XML is that we can very quickly throw complexity  
> which will bite us later when
> we try to express the same in a simpler language.  On the other hand,  
> we can start with TEXT or JSON to mitigate that risk, but then it's  
> more work to transform.
>
> Perhaps to finish... and in good SCRUM fashion... why don't we let who  
> ever has spare cycles produce a naive implementation of what we've got  
> now, in whatever his/her prefer language, and we look at it together!   
> If we don't like it, we throw it away and start again... but we'll  
> have learned something.  But this is only possible if we take small  
> steps at a time, otherwise it hurts to throw too much away... and pain  
> is not fun!!
>
> To conclude... I think we need to keep things simple... and if it's  
> simple it won't be a problem to support a wide range of content- 
> types.  If we don't want to do them all right away, but want to keep  
> the complexity beast at bay... we should then take small steps, have a  
> look at a running system, make sure it implements the spec properly,  
> realign and start again.
>
> Cheers,
>
> Meb
> PS.  In doubt... write code ;-)
>
>
>
>
> On May 7, 2009, at 6:56 PM, Tim Bray wrote:
>
>   
>> On May 7, 2009, at 1:12 AM, Marc-Elian Begin wrote:
>>
>>     
>>> I'm currently using restlet to build RESTFul web-services (very  
>>> nice by
>>> the way) in Java.  In such a framework, generating the requested  
>>> format
>>> based on the requests's 'Content-Type' attribute is trivial (as  
>>> long as
>>> the transformation is available).  This means that my WS can talk
>>> (x)html when the user's a human (me), or XML or JSON or plain/text.
>>>
>>> So for me multi-format is mandatory...
>>>       
>> Could you expand on you you get from "Generating multiple formats is  
>> easy for me based on my implementation tools" to "multi-format is  
>> mandatory"?
>>
>> The intervening steps in the argument are not self-evident.  -T
>>
>>     
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>