JSON Feed Announced As Alternative To RSS (jsonfeed.org) 201
Reader Anubis IV writes: With Slashdot recently asking whether we still use RSS, it may come as a surprise that something interesting has happened in the world of news feeds this week. JSON Feed was launched as an alternative to RSS and Atom, eschewing the XML they rely on -- which is frequently malformed and difficult to parse -- in favor of a human readable JSON format that reflects the decades of combined experience its authors have in the field. The JSON Feed spec is a simple read that lays out a number of pragmatic benefits the format has over RSS and Atom, such as eliminating duplicate entries, adding the ability to paginate feeds so that old entries remain available, and reducing the need for clients to scrape sites to find images and other resources. Given that it's authored by the developers behind one of the earliest, popular RSS clients and a recently Kickstarted blogging platform, the format is intended to address the common pain points currently faced by developers when producing and parsing feeds.
While it remains to be seen whether JSON Feed will escape the chicken-and-egg stage of adoption, several clients have already added support for the fledging format in the week since its announcement, including Feedbin, Inoreader, and NewsBlur.
While it remains to be seen whether JSON Feed will escape the chicken-and-egg stage of adoption, several clients have already added support for the fledging format in the week since its announcement, including Feedbin, Inoreader, and NewsBlur.
Obligatory XKCD (Score:5, Insightful)
Re: (Score:2, Funny)
It brings me an irrational amount of happiness to see that linked in the very first comment, since I had actually pulled up that strip and considered including it in the summary, but decided against it in the end.
Re: (Score:3)
Re: (Score:2)
I've beaten all of you: as soon as I read the beginning of the article, "xkcd 927" popped in my mind, without thinking.
Re: (Score:3)
Re: (Score:2)
Did we ever use rfc822 in the past? That seems like a no-brainer since it pre-dates all of these, and it is less awkward than all of these.
Bad reason (Score:5, Interesting)
People making mistakes implementing a spec is not in itself a good reason to drop it. There will be malformed JSON, that's to be sure. Do you escape slashes? Are true and false quoted? How long can a number be? Do the numbers use decimal dot or decimal comma — or does it depend on the locale? And, in the latter case, the server's locale or the client's?
I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.
Re: (Score:2)
It's only malformed and difficult to parse because people aren't using proper libraries for those processes. Every significant language out there has good libraries for reading and writing XML. There is no reason to have malformed XML in 2017.
Re:Bad reason (Score:5, Insightful)
good libraries for reading and writing XML
Let's take a look at the most used one, and see how many pages of serious security vulnerabilities [debian.org] it has. Many of them allow arbitrary code execution...
There is no reason to have malformed XML in 2017.
FTFY: There is no reason to have XML in 2017.
Re: (Score:2)
FTFY: There is no reason to have XML in 2017.
On what underlying serialization should XHTML, SVG, and ODF (OpenOffice/LibreOffice document formats) have been built instead?
Re: (Score:2)
Java is the one true language...apparently. Some people never learn.
Re: (Score:2)
Re: (Score:3)
Not for XML, but for JSON, I wrote my own library. Had to, one did not exist for the device that met the requirements. Not everything is a PC. And if you do want proper libraries, they will still disagree with each other! One problem I have seen more than once is the assumption that a library is correct merely because it's a library from a third party (as in my fellow coworkers are morons but anyone outside the building clearly has a comprehensive understanding of all the standards and was given enough
Re:Bad reason (Score:5, Insightful)
I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.
Yeah, what is the _actual_ problem that RSS/Atom are causing now?
I've written several RSS/Atom readers and writers and never once did I worry about "how hard" XML is to parse. Heck, since like 2003 I've only ever use a popular language library to read/write those formats. Who needs to even parse the XML except the first person to write the library for a new language? I iterate over an object's member objects; I don't parse XML.
It seems like the real problem being solved here is that XML isn't "new hotness" like JSON is, not that anybody is having a problem parsing RSS/Atom feeds. Were we starting over today, sure, use JSON, but we're not.
Re:Bad reason (Score:5, Insightful)
JSON is just XML from the Java ecosystem. Feature for feature...
Whoever made the decision to 'do it yet again' needs to be taken out and kicked square in the balls by every coder that has to waste time on this bullshit.
Re: (Score:3)
Its less verbose, more easily human readable, and doesn't have the "is this a property of the tag, or data inside the tag" problem. Its a better solution all around. I wouldn't create anything new in xml, but I wouldn't race to remove it in existing apps/protocols unless I'm doing a total v2.
Re: (Score:3)
Bullshit. XML with properties is just as tight. Not every property needs to be a subentity. There are decent Wiki articles that lay them out, side by side.
JSON more readable...no comments allowed. No, just no. WRONG.
They are feature for feature compatible, but one is Jave ghetto only, the other is 'everything else'. They should have never have _started_ on JSON, in hindsight it was clearly a mistake.
"is this a property of the tag, or data inside the tag"...I see your mistake. Use a library to parse X
Re: (Score:2)
I don't need a library, JSON is a native object or easily deserialized to a native object.
You see, the validation/serialization steps are moot and wasteful.
Invalid JSON is detected immediately, the semantics are arbitrary in both cases, so I'll have to test anyhow.
The true fallacy of XML is that "they" solved the data format with the view of a programming language.
That simply sucks if all you're doing is hoaling records from one point to another.
It's li
Re: (Score:3)
Actually, JSON is slightly lesser in functionality compared to XML. I can validate XML with an XSD spec (and I can transform it with XSLT). But in this context, it's easy enough to compare them based on how they are typically used.
Re: (Score:2)
Re: (Score:2)
I'm sure there's a xslt equivalent somewhere.
Re: (Score:2)
yes, but what JSON parsers already support JSON Schema validation without having to roll my own? Pretty much all of the XML parsers in the modern languages support XSD out of the box.
Re: (Score:2)
It's understandable that people hate xml (ever had to deal with namespacing issues?) but I don't get why people change to json and try to reimplement xml with it.
Re: (Score:2)
XML is too verbose and formal for simple messaging.
JSON provides an easy and quick way to transmit structured data, yet you're on your own.
The bullshit is on XML just the same as Java, far too much boilerplate for simple purposes.
But in the end, you'll have to personally make that connection work and check+test if the types match and are handled prop
Re: (Score:2)
JSON is a lot smaller. No schemas, properties, etc. It's just data definition and nothing more. Store your data in a bulky format, read it back again, send it over the network in a bulky but device independent manner, etc.
The reason for its existence is precisely because it is Javascript subset. No one invented a new library for it originally, it was just snippets of Javascript data declarations that someone used on their website.
Re: (Score:2)
I completely agree that RSS is great. If you hotness fans want to use JSON you'd best not break gPodder and the rest of the non Apple iTunes RSS podcast feed world or I will hunt you down and shove your keyboard up your nose. Thank you for your attention!
Re: (Score:2)
People making mistakes implementing a spec is not in itself a good reason to drop it.
Were that the sole difference, I'd wholly agree, but that's absolutely not the case here, which is why I tried to draw attention in the summary to some of the more substantive differences involved with this particular format. Had they simply ported RSS to JSON, this wouldn't be a story. Instead, they created a new format that is designed to address the issues they've faced in working with RSS and Atom over the last few decades, and in the process of doing so, it also made sense to switch to JSON.
I actually
Harder to malform the JSON (Score:3, Interesting)
People making mistakes implementing a spec is not in itself a good reason to drop it.
It is when the mistakes are frequent enough, obviously implementing RSS feeds is rather hard and most sites are really poor at it.
Adding to that is the simple fact that very few server languages have really easy or good XML generation at this point, compared to JSON library support. There are lots more good JSON libraries around and people are more comfortable with them and used to how they work.
There will be malformed JSON
Re: (Score:2)
Not at all true (Score:3)
The only coders using JSON now are java coders.
What about every web or server developer on Earth? Are you not aware that the entire industry has moved to JSON for client to server transmission? ALL of the server people I have worked with in the last decade now have preferred JSON for REST web service calls too. That includes Ruby servers, PHP servers, not just Java stuff. In fact REST was pretty much using JSON from day one except for a few crazy attempts to use XML instead.
The entire iOS development co
Re: (Score:2)
Um, you do know that the 'J' in JSON doesn't stand for 'Java', right? JSON is not from Java, nor is it some sort of Java standard.
XML may have its place, but JSON is a pretty good format for storing structured data and is generally far easier to use in a lot of programming languages (no property vs value confusion, it preserves type info for basic data types, maps really well to a lot of languages' native syntax, etc.). It's a great interop format too, is far less "noisy" to read and write, and is wildly po
Re: (Score:2)
Re: (Score:2)
Java and Javascript are two distinct words. You can't just chop a word in half and call it quits. Th wou b sil.
If we're going to be pedantic we should at least be pedantically correct.
Re: (Score:2)
LOL, nice trolling - well played. Have a great day!
Re:Harder to malform the JSON (Score:5, Interesting)
The only coders using JSON now are java coders. They made a mistake selecting their flat file, hierarchical data format. Should have just build a good XML library in java to start.
Point of order: I've read several messages in this thread where you misassociate JSON with Java, but JSON didn't come from Java.
Its source is right there in the name: Javascript Object Notation.
Now on to subjective matters: XML is a disgusting standard which should die a fiery death. And I say this as someone who works with XML on a daily basis (but more and more JSON these days, thankfully). The fact that good libraries exist to work with it doesn't make it any more palatable to me. JSON is vastly simpler, maps easily to the most common data types, and is (get this...) usually easy (for humans) to read.
Java and XML were stuck together at an early age, and their forced marriage was unfortunately very fecund... but even many Java developers have seen fit to move on, if they're lucky enough to have the chance.
Re: (Score:2)
I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.
Easier to read, perhaps, but I am not sure about writing.
It's not obvious when you use [ or {, , or |, when ; or quotes are required, and when spaces are significant.
XML seems to me to be far less error prone on the writing side, and they still manage to mess that up.
Re: (Score:2)
People making mistakes implementing a spec is not in itself a good reason to drop it.
I'd go father when it's this straightforward. We're not talking about race-conditions in kernel code here. If your web-devs can't produce a well-formed RSS feed, they're either morons on they're just not trying.
Re: (Score:2)
What about IPv6?
Question I have about JSON: will I be able to stage those feeds from my bookmarks bar under anything - FireFox, Chrome/Chromium or Edge?
Kickstarted blogging platform? (Score:3)
Re: (Score:3)
Good question. It made me curious so I checked it out. It's not a blogging platform but a micro-blogging platform. First thing I thought was, "So what?" Turns out they're using it as an alternative to bloated social websites that hoard your data. This micro-blog makes it easier to retain your own data, share it with others and easily move it to another service provider. Something like this might have the chance to do what Diaspora couldn't, namely, put ownership of the data with whom it belongs and make soc
Obvious solution (Score:5, Interesting)
Problem: XML is harder to write than JSON.
Proposed solution A: Invent an entirely new format based on JSON and have the entire world adopt it.
Proposed solution B: Write a small library that translates JSON to XML and just use any of the dozens of libraries that already exists to parse RSS feeds.
Let's go for solution A.
Re: (Score:3)
You've listed one problem, and were that the only one, you'd be right. But it wasn't. The summary itself obliquely mentions three other problems...
Problem: Duplicate entries frequently appear in feed clients.
Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.
Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.
Given all of those, a new format is not just the obvious solution, it's the only sol
Re: (Score:2)
A) The duplicate issue is a model problem. RSS doesn't require unique identifiers, so clients can't distinguish between outdated entries that have been removed and edited entries that have been replaced. We need to keep the former so the user can read them, but the latter need to be eliminated, lest we have both the original and edited versions in the client. Even if the publisher and the client both follow the RSS spec, it's still left to the clients to implement their own special sauce to recognize duplic
Re: (Score:2)
Most of what you're saying amounts to, "I haven't had any problems, so there aren't any", whereas I've actually had problems with each of these areas, so I'm looking forward to seeing the possibility of some movement in the space.
I'm just looking forward to a human-readable and more concise feed. XML is great for things that should be complicated, and terrible things that should not.
Re: (Score:2)
Atom only fixes the first problem I listed, so far as I know. If I'm mistaken, feel free to correct me.
Re: (Score:2)
Sure, which is why RSS was able to be built using XML. But if you want to fix the problems in RSS, you need something that isn't RSS. They could have implemented their ideas in XML and given it a different name, but if you're already creating a new format, why use XML when the library support in the relevant software stacks makes it far easier to export to JSON in far fewer lines of code?
Re: (Score:2)
It's about ads (Score:2)
I guess some sites don't want to appear in feed readers. Instead, they want the user to check back on the site's front page (and look at front-page ads) or to download and install the site's associated app for Apple iOS or Android with Google Play (and look at the app's ads, which are even harder to block without rooting).
Or the RSS feed might be delayed on purpose to discourage too-rapid polling. Slashdot, for instance, is known to ban IPs that retrieve its feed too often [slashdot.org].
Re: (Score:2)
Re: (Score:2)
If my business consisted in generating relevant amounts of public information, I would do my level best to make sure that everyone could access it as easily as possible.
You start by "generating relevant amounts of public information," accepting that your audience will include a small fraction of viewers who don't pay, be it through a subscription or through attention paid to advertisers who in turn pay you, counting on there still being a substantial fraction of viewers who do pay. But as viewers who pay become a smaller fraction of your audience, not enough viewers are paying to cover the cost of generating said information. The threat of operating at a loss means you nee
Re: (Score:2)
Are there any good RSS client out there... (Score:2)
Re: (Score:2)
I use RSS all of the time......just indirectly. I subscribe to a lot of podcasts which are under the covers, just glorified RSS parsers.
Re: (Score:2)
I linked to three clients in the summary. Of those, I personally use Feedbin and have been a huge fan of it ever since Google Reader shut down. It's operated as a for-pay service, but the developer open sources all of the code, so if you have your own servers you can run it yourself.
Oh FFS (Score:5, Insightful)
I remember when XML was the big thing and everyone was all, "Oooh oooh! Our solution will be so much better if we USE XML!!!11!eleventy"
I also remember then, how stupid this idea was, because there was nothing intrinsic about XML that would improve anything. Sure, XML is a human-readable file format that could be validated against a schema file if you so chose, and that was pretty good, but claiming a file/data format will improve how something functions, is like saying a car will perform better if you put the gas tank on the right side instead of the left.
And here we go, full circle again, except now everyone is ejaculating all over JSON, whose only benefit to XML is that it's slightly less verbose. It has none of the rigour that XML has, but everyone thinks it's great cause it's new and cool, and XML sucks because it's "old".
At least with XML, you can say enforceably say whether the piece of data is malformed or not. With JSON, the best you can do is basic syntax checking. There is no way to enforce the data itself is what it should be.... you have to trust that the other party didn't screw up the contents. The only way to add enforceability is reinvent the wheel in the worst way, by writing your own reference function to validate the data and hope other people use it.
Re: (Score:2)
How would you validate XML? If using XML Schema, then is it always possible to describe all interrelationships among elements and attributes in a schema? Or are you using XSLT to do whatever validation XML Schema cannot express? If so, that is likewise "your own reference function to validate the data".
Re: (Score:3)
XSLT is a presentation layer component, for translating XML into something else. If you're using it for validation, you're REALLY doing it wrong.
I won't go into details about what you can and cannot do with schemas because there are countless resources that can give far more detailed information than what I can do in a single slashdot post. Suffice it to say, Schemas may not be 100%, but for comparison, JSON has no equivalent to schemas at all.
An AC in another post pointed to a project that is attempting
Re: (Score:3)
JSON Schema [json-schema.org] is a vocabulary that allows you to annotate and validate JSON documents.
Re: (Score:2)
XML was never really new...It was intended to be the last time anybody had to implement flat file hierarchical data stores.
We see how well that worked. If it had worked, JSON would have never been invented. But they neglected coders need to piss all over standards before using them. JSON is XML, with all the deck chairs rearranged.
Re: (Score:2)
At least with XML, you can say enforceably say whether the piece of data is malformed or not. With JSON, the best you can do is basic syntax checking. There is no way to enforce the data itself is what it should be
Oh? Then what's this [json-schema.org] then? Eagerly awaiting your informed and educated response.
Re: (Score:2)
Re: (Score:2)
Ever heard of Json Schema ?
Nope. Good to know! It would have been infinitely better to have something that was actually part of the JSON spec, but this is a second best option.
http://json-schema.org/ [json-schema.org]
Re: (Score:2)
It would have been infinitely better to have something that was actually part of the JSON spec, but this is a second best option.
And also, I understand this to me that if XSD was not part of the XML specification that XML Validators wouldn't work nearly as good then eh? You better quit while you're ahead.
Re: (Score:2)
Re: RSS was too open (Score:2)
RSS worked fine, the problem is it was too open. Publishers want you logged in and monetized, with a reader that will display ads, and subscribing through a smart phone app.
Man I remember the good old Google Reader days RSS feeds were so well populated that I didn't bother going to websites anymore. RSS feeds had everything I wanted. But yeah those glory days feel like they're gone now. I haven't made the switch to feedly yet and this point I'm not sure I'm going to bother with it.
I annonce new formats... (Score:5, Insightful)
YAML Feed
INI Feed
CSV Feed
PROTOBUF Feed
THRIFT Feed
TSV Feed
TXT Feed
{NEW TRENDY FORMAT} Feed
Podcasts would be the adoption moment I think. (Score:4, Interesting)
Since the death of Google Reader my most used case of RSS is podcasts. I get the occasional feed notification from IFTTT but most of the websites I used to get RSS from just have direct channels that are a little better and a little easier.
But podcasts however I listen to a fair number of podcasts and I have about 30-40 of them in my reader (Podcast Addict [google.com]). I'd like a readable JSON format for syndication but if it's going to mess with my podcasts I won't bother.
RSS is dead and replaced by... (Score:2)
In a society based only on acquisition of wealth.. (Score:2)
Only adding confusion (Score:2)
This new standard will only cause confusion.
The big parties like Google are already trying to rid the world of RSS, or relegate it to a niche, since there is no advertising money in it.
There is all kinds of things wrong with XML, but not in the context or RSS Feeds. The format is simple, easy to create and easy to read. Adding a new standard will not make RSS Feeds suddenly popular, quite the opposite.
Let's unite behind RSS and the XML format.
XML is not the problem (Score:2)
The data format isn't the problem. It's that the current web industry does not promote decentralized content distribution when it cannot be used to distribute advertisements and collect consumer metrics.
iCalendar is a custom property list format (SOMETHING:VALUE) and there is no real need to replace it either. As the problems aren't the format, but in how applications choose to use, distribute, and interoperate.
The problem lies way way above the software. It's with people, the businesses and users.
ASN.1 feeds announced as alternative to RSS (Score:2)
On second thought... we need a version that uses protocol buffers.. this would make RSS even better. You'll never know it or care but it'll be better...trust the Internet... more fragmentation for semantic bullshits sake is good for everyone.
ORLY? (Score:2)
Tell me it's a joke.
I can read XMLs - no problem, most JSONs on the internet have no new lines at all, thank you very much.
date_published is optional? Noooo... (Score:3)
It's a lot easier to parse a feed into a series of articles if each article entry has something in it that gives a natural ordering.
It's a lot easier to display an integrated collection of feeds if articles have a natural ordering relative to each other.
It was a problem that RSS didn't make publication date mandatory. JSON Feed doesn't solve this problem.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes because everybody knows he could have used a regular expression [stackoverflow.com].
Re: (Score:2)
Yes because everybody knows he could have used a regular expression.
I don't recall using regex for my XML parser in Java. If I did, I would probably have gotten a book on regex (which I don't have). I did have a brief exposure to regex in my Linux administration classes. Never took Perl because the class got cancelled for not enough students. These days I used regex with Beautiful Soup to parse Slashdot comments in my Python script.
Re: (Score:2)
In the early 2000s Creimer got a free education.
I had a $3K tax credit. I spent my own money on school and got reimbursed on my tax refund. Did that for five years while taking two classes per semester. The three all-day Saturday ceramics classes I took during that time I paid out of my own pocket.
He's a scumbag, nah I'm just kidding, he's a great person.
Still jealous that the dean recommended me for the president's list because I maintained a 4.0GPA in my major? Shame, brother, shame. ;)
Re: (Score:2)
You seriously need to stop replying to this.
Re: (Score:2)
You seriously need to stop replying to this.
The alternative is to listen to my co-workers on the all-day conference call talk about storming medieval castles in Germany. It's a slow week as Memorial Day weekend is coming up, everyone who is important is on vacation, and this month's scan data is nowhere to be seen.
Re: (Score:2)
They're all tourist traps. The beer is cheaper, further away from the castles. Storm a beer garden instead.
Stay away from Oktoberfest. It's just an insane ripoff in the tents.
Re: (Score:2)
They're all tourist traps. The beer is cheaper, further away from the castles. Storm a beer garden instead.
I don't think they had beer gardens back in medieval times.
If you're going to storm castles, you need one of these for the tabletop game.
http://www.apptivus.com/store/pennypult-toy-trebuchet-kit [apptivus.com]
Re: (Score:2)
Otherwise we get "web monkeys" who load jQuery before writing a single HTML tag for a text-only, non-interractive page that displays a simple "Hello world" sentence.
Re: (Score:2)
Otherwise we get "web monkeys" who load jQuery before writing a single HTML tag [...]
How do you load jQuery without writing a script tag?
https://www.w3schools.com/jquery/jquery_get_started.asp [w3schools.com]
Re: (Score:2)
What is XML even used for? Seriously, wasn't it supposed to overtake HTML at one point? Who uses it and for what purpose?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
People who don't want to always have to put things down, reach for a cell phone used as a pocket watch, and turn it around if upside down. Cyclists, for one.
Re: (Score:2)
Re: (Score:2)
But in reality, a watch is quite impractical because the time gets all blurry from the motion of your wrist when you masturbate.
Re: (Score:3)
But in reality, a watch is quite impractical because the time gets all blurry from the motion of your wrist when you masturbate.
Yes, and a watch is very important during those times because you have to keep an eye on you watch to make sure you don't go beyond 4 hrs.
Re: (Score:2)
Ah yes, a Viagra joke, implying that I am old and need such a thing. Well played.
Re: (Score:2)
You don't own a real Rolex?
Re: (Score:2)
For a while, all the cool people stopped wearing them, looking at you like a hopelessy out of touch dinosaur if you kept a watch. Then very quickly that reversed itself, now all the cool people and hipsters wear smart watches, Fitbits that tell time, and other time telling devices worn on the wrist. AND normal old fashioned analog watches are appearing on peopel's wrists.
The lack of wrist watches was one of the shortest lived fashion trends that I can remember.
Re: (Score:2)
And frankly, there are libraries to correctly build & sanitize the contents of both XML and json, so there is no excuse for that
Other than trying to interoperate with existing sites' incomplete or invalid feeds while avoiding copylefted code.
YAML (Score:2)
I propose we improve this by using human readable text files for feeds. Just straight old readable text.
Something like YAML [yaml.org], a more "human-readable" serialization intended to fill some of JSON's niche?
Re: (Score:2)
I've read over the years that JSON data size is smaller? Also read that gzip negates this transparently.
XML will still compress smaller than JSON because gzip still has to emit back-references for the end tags. It's similar to how minified JS compresses smaller than unminified JS.
CORRECTION (Score:2)
Change "XML will still compress smaller than JSON" to "XML will still compress slightly larger than JSON".
Re: (Score:2)