JSON/XML/something else..

[Praveen Alavilli]

Following up on the discussion in agile-banking group about if Atom is a bit heavy weight compared to JSON - the reason why we chose Atom currently is because of it's simplicity - even though it's XML the Atom schema is pretty simple, easy to understand, and there are a lot of libraries/sdks/toolkits already available to create/process Atom entries.  And of course there are already ways to represent Atom feeds in JSON too - for eg. Google's GData APIs does this in a nice way (http://code.google.com/apis/gdata/docs/json.html). 

Is that sufficient ? Are there any use cases where the proposed Atom based document model wouldn't fit ?

cheers,
Praveen

[Pelle Braendgaard]

I think Atom could be a good choice for transaction data, mainly
because there already is infrastructure for it. It also does
encapsulate the idea of a feed.

It might not be as easy though for many developers to extract the
transaction data using most of the atom libraries, which is why there
are libraries for dealing with for example the gdata apis.

There doesn't have to be only one data format as you mention. There
should be json and probably also a micro formatted html version. I
think though that XML is a bit of a dying standard outside the
enterprise development world and it would be better to pick JSON as
the default minimum requirement and Atom/XML as an option. If for no
other reason, this would allow widgets etc to be written in Javascript
to easily interact with the financial data.

Contrast Facebooks new API: http://developers.facebook.com/docs/api in
understandability with the GData apis:
http://code.google.com/apis/gdata/docs/json.html

For the actual transaction creation, I do think XML is a very bad
idea. Even JSON is probably overkill. URL encoded form data is
supported easily by every single platform without using any thing but
the basic http library.

P

--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking

[Ray Tanaka]

Pelle -

I agree that XML may be a bit heavy. Our proposal wasn't meant to
focus on the fact that an ATOM feed was intended to be represented in
XML. We chose to base our proposal off of ATOM based on the similarity
of that of an ATOM entry and a single transaction. Also, the life
cycle of an entry (e.g. how it's updated and modified) is also nearly
identical to that of a transaction.

While I understand there are certain aspects of an ATOM feed that make
it difficult to freely convert back and forth between XML and JSON.
It's our hope and intention to make sure that is the case. Not to
mention I personally prefer working with JSON over XML.

For simple transaction with a single amount, I can see how anything
other than url encoded data does seem like overkill. I do, however,
feel like the ability to represent multiple items in shopping carts
and multi-merchant marketplace scenarios should be supported and would
require more of an object oriented approach.

It's clear you've put quite a bit of thought into this space and I
appreciate your feedback.

- Ray

> --http://agree2.com- Reach Agreement!http://stakeventures.com- My blog about startups and agile banking