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

[CEW]

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