You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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:
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.
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.
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.
This not an agreement between most of rss producers (WP, blogspot) and consumers (Feedly, FeedReader, Akregator, Thunderbird, MS Outlook, QuiteRSS, Liferea and many others).
It doesn't adds any new semantic value needed for modern content: comments, likes, tags, content cut, mentions, synchronization rules etc.
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.
@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.
Activity
manton commentedon May 17, 2017
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.
eric commentedon May 17, 2017
I think this is a common enough scenario that it's worth addressing in the spec.
donohoe commentedon May 17, 2017
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
donohoe commentedon May 17, 2017
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
manton commentedon May 17, 2017
Thanks @donohoe! Good to see these examples of different JSON formats from The New Yorker.
dissolve commentedon May 31, 2017
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.
croaky commentedon May 6, 2018
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!
khalwat commentedon Aug 25, 2019
Also am in need of an update to the spec to allow for multiple authors.
I implemented it assuming that
authorswas an array of object, which ends up not being the case.stokito commentedon Jun 16, 2020
Atom have the separate contributor tag.
So you can introduce the similar array
contributorsalongside of author.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.
manton commentedon Jun 16, 2020
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.
stokito commentedon Jun 20, 2020
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:
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.
The same as with the
contributorsand 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:
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.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.
manton commentedon Jun 20, 2020
@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.