The last few years we've been using a simple online store application to demo application composition with SCA. That store app allows you to pick fruits and vegetables out of a catalog and put them in your shopping cart.
Here's the XML currently produced from Java bean representations of the cart, fruits and vegetables using some fancy JAXB code:
<ns2:root xmlns:ns2="http://tuscany.apache.org/xmlns/sca/databinding/jaxb/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="cart">
Here's without the namespace mess, as it's not needed by the store app to disambiguate what's flowing (as the app knows what it's doing), and would probably over-complicate any non-XML representation as well...
That looks a little better.
Here's with attributes instead of elements. It's shorter and should work too, I guess?
<fruit name="Apple" price="2.99"/>
<fruit name="Orange" price="3.55"/>
<vegetable name="Broccoli" price="1.99"/>
The problem is that over the years I've started to develop an allergy to XML (mostly because of the usual namespace mess), so let's go with the flow, be cool, and try JSON...
Here's a possible JSON representation. The cart contains an array of objects, actually two levels of objects to distinguish fruits and vegetables.
Another try, with the funky javaClass attribute expected by the Java JSON code to figure the type of each item in the cart... Not great.
Here's another one following the Jettison or Badgerfish XML / JSON mapping. Multiple items of the same name are grouped in an array field. So in my example fruit is an array, vegetable is not. Now, add another vegetable to your cart, and vegetable morphs into an array... Confusing for lack of a better word :)
Let's try a little harder and find alternative representations:
cart: - type: fruit
- type: fruit
- type: fruit
- type: vegetable
I still need to add an artificial 'type' attribute to each item to represent different fruit
(fruit (name "Apple")(price 2.99))
(fruit (name "Orange")(price 3.55))
(vegetable (name "Broccoli")(price 1.99)))
That Scheme language representation is not bad at all!
- it's really concise;
- the Scheme syntax is simple and easy to parse, () for lists, space as a separator;
- as the above expression is just constructing lists, I don't need to make my shopping cart data fit in Objects, Arrays or Maps;
- it's easy to distinguish symbols like fruit or name and user data like "Apple".
- a list can simply be tagged with a fruit or vegetable symbol to indicate its type;
- like JSON, the above expression is a piece of code easy to evaluate and test in a Scheme interpreter.
Another variation on the same theme with Python tuples, as Python is more widely known than Scheme or Lisp.
A little more verbose than scheme, but not bad.
So, I must admit... I think I much prefer the Scheme representation, or the Python tuple syntax. I realize that Scheme was created in the 70's, but hey, that doesn't mean it's bad :) -- see the Wikipedia entry on Scheme for its history.
Oh, by the way... check-out that JSON parser page. Here's what it says:
Why not just stick with Scheme's minimalistic syntax then? Why would I need JSON's C-like syntax or these fancy soft objects to represent my shopping cart? :)
Let me know what you think...