Re: Content types and links

hello eric.

On 2012-09-06 20:52 , Eric J. Bowman wrote:
> I don't know your requirements, but I'd wait until the desired feature
> (Atom serialized as JSON) actually exists before implementing it, rather
> than trying to hit a moving target.  Once application/atom+json is
> nailed down, it's easy enough to add in support to please client
> developers, without the extra complexity of supporting legacy code.
> Client developers can then remove their transformation layer, and change
> their Accept: header to request atom+json instead of atom+xml.

is there an ongoing activity for this? afaict, many people want to use 
atom's model in JSON, and many create custom mappings. the problem with 
a standard is that atom is fairly tightly narrowed to XML, in particular 
when you look at its extension model, and it seems to me the two 
fundamental options you have are both not that appealing (which i think 
is why we do not have atom in JSON yet):

- leave out the complicated XMLy parts and end up with something that is 
only a subset of atom's model and thus cannot represent all possible 
atom+xml documents. not good.

- map everything to JSON and end up with sometimes horrible JSON, in 
particular when people use extensions and these extensions contain XML 
markup. not good.

i am just curious (because you recommended to "wait") how you think this 
dilemma will be solved, and whether you know about an activity where 
people are actively working on a solution.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |