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

[Marc-Elian Bégin]

Right... forgive me then.  And I apologies if I'm wasting anybody's  
time.

What's the approach you want?

Meb

On May 7, 2009, at 8:35 PM, CEW wrote:

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