Behavior for multiple authors about jsonfeed HOT 12 CLOSED

I think this is a common enough scenario that it's worth addressing in the spec.

from jsonfeed.

For feeds with multiple authors, each item can have a different author. For multiple authors on a single item, the spec doesn't really say anything about that. I've seen at least one person put "Name 1 and Name 2" as the author name, though. That's probably the best approach for now.

from jsonfeed.

Agree. Multiple authors is very very common. This is the basic format we followed at The New Yorker:

Source (continuously updated so examples will fall in and out over time):
https://www.newyorker.com/open/latest.json

from jsonfeed.

Adding another example from The New York Times, where its just a simple array:

http://json8.nytimes.com/services/json/sectionfronts/world/europe/index.jsonp

from jsonfeed.

Thanks @donohoe! Good to see these examples of different JSON formats from The New Yorker.

from jsonfeed.

Is this useful for readers though. Feed Readers really only have space for a single author image. At that point shouldn't it list the publication?

Not saying i'm against it, just worth questioning.

from jsonfeed.

I love the spec! Great work, all.

I had the same need as others on this thread. Took a stab at editing the spec to support multiple authors:

#120

Let me know what you think!

from jsonfeed.

Also am in need of an update to the spec to allow for multiple authors.

I implemented it assuming that authors was an array of object, which ends up not being the case.

from jsonfeed.

Atom have the separate contributor tag.
So you can introduce the similar array contributors alongside of author.

Adding another example from The New York Times, where its just a simple array:

That's a bad idea to have two representations of the same field. Especially this become a big problem for static typed languages like Java where JSON-to-bean mapping libraries like Jackson can't handle such scenarios.

P.S. Why are you inventing the new spec if you never read already existing specs and how they used? I just shocked that you are trying to create a new standard in the area where we already have too much standards while in fact just plain RSS is good enough and easily extensible with namespaces.
Instead just contribute to existing libraries to make them all working in the same manner.
WordPress which covers 90% of real life RSS content so it can be the only one real standard. And it produces quite interesting RSS with inclusion of some Atom tags and even some Slashdot (!) tag which is already widely supported by RSS readers.

from jsonfeed.

The draft of version 1.1 of the spec has support for multiple authors, so I'm going to close this now. As for "why JSON Feed"… It has already proven very useful since the original spec was published a couple of years ago, and has good support in a bunch of apps and tools.

from jsonfeed.

I may sound rude but someone must tell it to you. Please, don't call the "Proposal for JSON Feed version 1.1" a "draft" and don't call the JSON feed a "specification". Just read any real specification to see what exactly does it mean. This is extremely boring but just check issues to the repo: half of them are basic clarification questions about how to interpret JSON feed description.
Any specification should have at least two implementations from different vendors. But here we see that it's just you personally decided what will be added to the spec without any discussion with implementors.

Just for example:

Multiple authors (#6). Allow an array of authors instead of just one wherever we had a single author before.

This means that you are going to break rss feed consumers because previously they expected a single author object but now they'll receive an array.

Add language

The same as with the contributors and other tags that already exists in Atom and RSS. You simply reinventing a wheel here.

But I still didn't get the reason why the JSON Feed is needed:

1. XML parsing and generation is not a hard task at all and all needed tools for this are part of std lib on all platforms (except of BusyBox and OpenWrt). XML parsing is fast and. It uses almost the same place as JSON when gzipped.
2. It is easy to transform to JSON e.g. in Android JSONObject jObject = XML.toJSONObject("rss xml content"). The only one problem is structural difference between Atom and RSS. There is plenty of libraries like rss-parser or rss-to-json that leverage differences.
3. Feed is just a machine to machine protocol and no needed to be read by humans. Anyway in JSON form it's much harder to read feed.
4. This not an agreement between most of rss producers (WP, blogspot) and consumers (Feedly, FeedReader, Akregator, Thunderbird, MS Outlook, QuiteRSS, Liferea and many others).
5. It doesn't adds any new semantic value needed for modern content: comments, likes, tags, content cut, mentions, synchronization rules etc.
6. This is not an attempt to standardize existing solutions: fortunately, there no any other except of ActivityStreams and rssjs.org "spec" which was proposed to WP and even implemented as a plugin.

It's absolutely clear that you didn't made any effort to learn existing solutions. We already had a situation when a new protocol Atom was developed instead of evolving and standardize old RSS. This leads to a lot of confusion and in the end the really useful Atom tags just was used with RSS. But the Atom is at least a real specification that is explicit as much as possible.

from jsonfeed.

@stokito I'm not sure what you are trying to achieve here. JSON Feed has been widely implemented for 2 years in many apps, including popular feed readers, IndieWeb tools, scripts, countless web sites, etc. It's here and works well. RSS is also great! Many people contributed to JSON Feed (see "Reviewers") and the goal was to create a readable specification that would be helpful even to people who aren't programmers.

from jsonfeed.