I would seriously recommend against XML. While I agree it won’t be going away for this stuff, it should. It’s easy to get XML wrong or to make it fit a particular cognitive bias for what data should look like. Or to pile on schemata and namespaces and make a beast so goofy it requires a manual to formulate a basic API request and parse the results.

JSON is nude Arrays, Hashes, Strings, Integers, and Booleans. It is what it is and it’s UTF-8. I would *never* use XML as the serialization or data layer in a project if I had the choice. And I resent the hoops through which I have to jump due to it being every Java hackers first choice.

Ajax was only XML at first, hence the “x.” Today hardly anyone is doing it in anything but JSON. It wasn’t a corporate agenda that did that, it was path of least resistance and fewest bugs.

More than KISS, I’d say use the abstractions that abound. There are a couple dozen *excellent* JS kits now that take away the pressure of having to deal with browser nonsense. There are as many nice CSS templates which will gracefully adjust to monitor size, be it a phone or a cinema display. The guts of a CMS can be written in Catalyst/REST or Mojo or Dancer or Amon2 or… in a week by anyone who has experience; mix in Oauth2 or something and you don’t even have to keep formal user accounts or manage password issues. A beginner might need three months…and that includes getting help when necessary, but it is worth it and doing it on your own means you become more employable should you choose to go that route.

WOW Your Mother, I've been blessed twice, in one day. I've got goose-bumps. :)

Seriously. I really appreciate your concise, well justified argument for JSON, and friends.

I'm not going the Dancer, Catalyst approach (in the near future, anyways). But would still be a reasonably small effort, if need/want be. OTOH I can easily see why JSON vs XML == JSON. As I mentioned, only too many times already. I'm a BIG fan of UTF-8. Frankly, that's reason enough. But your other well articulated reasons, only further my wish to now choose JSON.

Mind you, my initial resitance to Dancer, Cata...,{...}, is because I've become all too well aquainted with Apache, and Apache-like servers. So habits (good|bad) are really hard to break. Further; I come from a Function, Routine flow, where programming -- esp. Perl, is concerned. So while I'm no novice, JSON is going to be a bit of a learning-curve, for me. I hate OO, and all it pretends to be. Could a worse name have ever been conceived? Define Object, I double-dog dare you. Nobody, and Everybody is an OO expert, the whole topic, can not be accurately defined -- too nebulous. That's my NotSoHumbleOpinion. But Perl, and mostly where Modules are concerned; is going by way of OO. So I'll just roll with it. But, for the record, it's going to be a struggle. :P

Thank you very much, Your Mother. For a perfectly worderful evaluation. Much appreciated.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Speaking of recommending JSON, over {...};

Any examples of JSON usage/in use, you (or anyone) would recommend. That I could draw from?

Thanks.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

I don't have time to go dig up examples from where I've used JSON but I wanted to tell you what I find to be the greatest virtue of JSON: cross-platform objects. Oh yeah, and the main reason people use it is that it's much less verbose than XML (less bandwidth).

If you pass JSON into javascript, it's trivial to inflate the object, add a prototype and "bang! it's an object with behaviors". Typically you would have methods that display, edit, whatever that data. When you're done, you pass the JSON core (data) back to your Perl server. On the Perl side, you can easily inflate the JSON to a hash and bless it into a class that provides persistence (or whatever). Well, anyhow, that's what I find awesome about JSON.