Nick,
The premise of our mediatypes and parameter/payload types in general is to work with "structure" representations, not format encodings.
In other words, everything internally is built to "load" and "render" type definitions into ruby hashes: hashes are the canonical internal representation of things. Nothing in the innards of the code assume or rely on JSON or any other format.
This means that it is only in the last moment that you'd want your "format" your rendered hash. Or only at the begining of a request that you want to "load" the incoming formatted message into a ruby hash.
On the output, if you like JSON for your APIs, you simply need to do JSON.dump( rendered_hash ) in the controller action... but you can as well feed the hash/array into any XML generator that can take incoming ruby hashes/arrays.
On the input side, that's a little more limited now. At the moment, Praxis will only be able to "load" payloads that are JSON encoded (and form-encoding) into the payload types. This means that it is not going to parse XML bodies. That can certainly be enhanced, and we should make it easy for you do add extra payload parsers (based on incoming content types). The plugin work that is coming soon should make that extension easier.
In terms of using Roar, (or its `representable` underlying gem) I don't quite see the benefit or how it would even work, as:
* I do think that the attributor syntax and type extensibility is much cleaner, easier and better (completely biased opinion :) )
* Like I said above, Praxis focuses in "structures" and not encodings...and those two things are built together in Roar.
* I "'"think""" (with triple quotes) that the performance of attributor is better...although this would require much more investigation and proof than me saying that.
That's just my 2 cents about it,
Josep M.