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

[Chris Webb]

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.