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

[Marc-Elian Bégin]

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
>