Links to identical feeds in other formats

[jbrayton]

There is no good way to programmatically determine that a JSON Feed is simply a JSON Feed version of a specific RSS Feed. This is particularly problematic when a site has multiple RSS feeds and multiple JSON Feeds or when a single web page links to multiple RSS feeds and to multiple JSON Feeds.

For an app like Feed Hawk that allows the user to subscribe to feeds based on a web page, this means that the app has little choice but to list all RSS Feeds and all JSON Feeds. Ideally it would present the list of substantively different feeds and whether the user is subscribed to each feed without regard to whether the user is subscribed to the RSS version or to the JSON Feed version.

This also doubles the work of feed aggregation services. A feed aggregation service needs to periodically retrieve each RSS Feed and each JSON Feed. Ideally such a service could convert an RSS Feed subscription to its JSON Feed equivalent if one exists.

In order to address this I propose the addition of an optional "alternate" object:

"alternate": [
  {
    "format": "RSS 2.0",
    "url": "https://jsonfeed.org/xml/rss.xml"
  },
  {
    "format": "Atom 1.0",
    "url": "https://jsonfeed.org/xml/atom.xml"
  },
  {
    "format": "Not-yet-invented YAML-based format 1.0",
    "url": "https://jsonfeed.org/feed.yaml"
  }
]

A JSON Feed would be in violation of the spec if it listed feeds in this section whose content varied substantively from its own content.

If there is consensus that this would be a worthwhile change I am happy to open a pull request with a draft of it. I also realize that even if there is consensus this may need to wait for a future version of the spec.

Thank you for your work on this. I am excited about JSON Feed.

[manton]

Thanks for the suggestion. Related to this, I noticed that the podcast production app Cast has an rss_url field in their JSON Feed extension, for a similar purpose. http://help.tryca.st/cast-jsonfeed-support/

[da2x]

This is already solved in HTTP with content negotiation. It’s not needed inline in the format. See issue #84.

[jbrayton]

@da2x I like the idea of using content negotiation for this. I would like to see blog engines and content management systems do so. That said, I am skeptical that using content negotiation for this will be common anytime soon because of the way WordPress works with caching plug-ins and because of static site generators.

[da2x]

It's the right tool for the job. It's a well established standard that is well supported by existing HTTP infrastructure. It's well supported with static files on Apache. It's well supported by caches and proxies. It's also very easy to implement with a lot of reference material.

It does require issue #84 being woeked out first, however.

[KyLeggiero]

@da2x @manton Is JSONFeed necessarily tied to HTTP? If not, it should have its own way to regain what it loses when operating outside HTTP.

[dshanske]

What is the use case for JSONFeed mentioning the RSS version of the same file?

[jbrayton]

The header on jsonfeed.org, for example, contains these alternate links:

<link href="https://www.jsonfeed.org/feed.xml" rel="alternate" type="application/rss+xml" title="JSON Feed">
<link href="https://www.jsonfeed.org/podcast.xml" rel="alternate" type="application/rss+xml" title="Podcast">
<link rel="alternate" type="application/json" title="JSON Feed" href="https://www.jsonfeed.org/feed.json">

I believe the first and third feed contain identical content. If the user of an RSS reader says they want to subscribe to the site, the RSS reader typically says here are the feeds, to which one(s) would you like to subscribe?

Knowing that the first and third feed contain identical content would allow the RSS reader to consolidate them rather than offering two identical feeds. (Perhaps the <link> elements would be a better place to provide this information?)

[manton]

Putting this information in <link> itself is an interesting idea. I wonder if anyone has experimented with that in the past, maybe with data- attributes? Skimming through the standard attributes for <link>, I don't see any that would be appropriate.

[dshanske]

@jbrayton That's the HTML header, not the http header. This question is about putting it inside the feed file itself... which seems redundant...if you asked for the JSONFeed version... why would you also want the RSS version? If you visited the actual resource the feed reflects, the rel alternate links would be there

[pfefferle]

@manton the data- attribute should not be used to set accessible data:

Do not store content that should be visible and accessible in data attributes, because assistive technology may not access them. In addition, search crawlers may not index data attributes' values.

https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes