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

[Sam Johnston]

I was thinking more about the text format today (still believing there
is significant value in multiple formats and slightly more work for a
small handful of implementors VA an infinite number of clients) and
was thinking RFC 822 ala HTTP headers could be interesting too...

No need to be anti-XML... if you want to start from text and code the
translations by hand then you're most welcome to do so.

Sam

On 5/7/09, Chris Webb <chris.webb at elastichosts.com> wrote:
> Andre Merzky <andre at merzky.net> writes:
>
>> +1 for TXT, as that is most simple, flat, and easy to map to
>> anything else.  Well, you can screw up TXT, too, but we
>> won't, right? ;-)
>
> I'm standing back from the rest of the discussion as I've already advocated
> maximum format simplicity ad nauseam. However, I'll just quickly point out
> that the type of text format I have been proposing is a simple
>
>   KEY VALUE
>   KEY VALUE
>
> format, which can be read by a trivial shell fragment
>
>   while read K V; do [...]; done
>
> Once it gets more complex than that, the sysadmin-friendliness starts to
> evaporate very quickly and you might as well use JSON. (For example, I
> remember another provider telling me that they'd offered CSV and nobody had
> used it. Frankly I'm not surprised given how much of a pain it is to parse
> correctly.)
>
> In our own API, our 'native' format looks like this and it has worked very
> well. The code is simple and clean, feedback from users has been very
> positive, and people really do write five line shell scripts to drive our
> infrastructure in the way they might script their own machines. This was my
> original design aim. Meanwhile, we're able to do admin across the cluster
> with shell one-liners, which would require separate tools if our API were
> more clumsy.
>
> We've structured our keys hierarchically using colons as a separator, so a
> text fragment
>
>   ide:0:0 08c92dd5-70a0-4f51-83d2-835919d254df
>   nic:0:dhcp 91.203.56.132
>   nic:0:model e1000
>
> might be viewed as equivalent to the flat JSON hash
>
>   { "ide:0:0": "08c92dd5-70a0-4f51-83d2-835919d254df",
>     "nic:0:dhcp": "91.203.56.132",
>     "nic:0:model": "e1000"
>   }
>
> but equally as equivalent to the nested JSON hashes
>
>   { "name": "TestServer", "cpu":4000, "mem":2048}
>
>   { "ide": {
>        0: {
>          0: "08c92dd5-70a0-4f51-83d2-835919d254df"
>        }
>     },
>     "nic": {
>       0: {
>         "dhcp": "91.203.56.132",
>         "model": "e1000"
>       }
>     }
>   }
>
> The use of whitespace to separate keys from values and newlines to separate
> records restricts keys (but not values) to contain no spaces, and both keys
> and values to have no leading whitespace or embedded newlines. In our
> environment, this isn't a problem, but you would need to add shell-friendly
> \ escaping to the mix if you wanted to allow demented keys and values in a
> whitespace-separated text format.
>
> Of course, if the standard goes with just JSON, it isn't a disaster from our
> point of view. We'll probably end up offering a small translation binary
> linking against libcurl to access it in the above flattened format. Seems a
> shame to force every casual user to compile and use a tool just to make the
> API usable from their command-line, though, when this isn't currently the
> case with our API.
>
> It'll be hard to sell something like this to end-users as an improvement,
> but definitely less hard-to-sell a little JSON-parsing binary (which I could
> write standalone) than if the tool also needs you to compile and link
> against cumbersome XML and Atom libraries (which I wouldn't even think of
> trying to do standalone). I guess my vote is there strongly anti-xml/atom,
> vaguely positive about json, and strongly positive about simple plaintext.
>
> Cheers,
>
> Chris.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>