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

[Marc-Elian Bégin]

What 'tools' to you have in mind?  Or can you point me to a previous  
thread if this has been discussed already?

Meb


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

> A descriptive language and tools to translate it to whatever form  
> the heart desires.
>
> C.
> Marc-Elian Bégin wrote:
>> 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
>>>>
>>>
>>
>