Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
IT News Technology

JSON Feed Announced As Alternative To RSS (jsonfeed.org) 201

Posted by msmash from the moving-forward dept.
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.
This discussion has been archived. No new comments can be posted.

JSON Feed Announced As Alternative To RSS More

JSON Feed Announced As Alternative To RSS

Comments Filter:

  • Obligatory XKCD (Score:5, Insightful)

    by ttyler ( 20687 ) on Wednesday May 24, 2017 @12:43PM (#54477909)
    https://xkcd.com/927/ [xkcd.com]

    • Re: (Score:2, Funny)

      by Anubis IV ( 1279820 )

      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.

    • Except JSON is hardly a new standard, and RSS feeds are so inconsistent with their XML it wasn't much of a standard, either.

      • Re: (Score:2)

        by Mozai ( 3547 )
        That's the joke. We used to use SGML-dialect "HTML", we came up with two flavours of XML, and the solution proposed it to come up with yet another one-right-to-rule-them-all standard.

        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)

    by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Wednesday May 24, 2017 @12:53PM (#54478007) Homepage Journal

    eschewing the XML they rely on -- which is frequently malformed and difficult to parse

    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.

    • 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)

        by KiloByte ( 825081 ) on Wednesday May 24, 2017 @01:20PM (#54478291)

        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.

      • 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)

      by bill_mcgonigle ( 4333 ) * on Wednesday May 24, 2017 @01:09PM (#54478171) Homepage Journal

      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)

        by HornWumpus ( 783565 ) on Wednesday May 24, 2017 @01:27PM (#54478355)

        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)

          by AuMatar ( 183847 )

          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.

          • 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

            • Use a library to parse XML, don't roll your own.

              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)

          by SQLGuru ( 980662 )

          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.

          • This is an excellent point. I've been extremely frustrated with software that has been using JSON or YAML lately since they don't provide specs for their format. It often takes a lot of guesswork to determine if an entity is a subentity and if so, what is the parent entity, is this entity a list, is the entity a String that requires quotes or a non-quoted data type. These standards are a bit more pithy but a lot more ambiguous.

          • Re: (Score:2)

            by t0y ( 700664 )
            Way ahead of you: http://json-schema.org/ [json-schema.org]
            I'm sure there's a xslt equivalent somewhere.

            • Re: (Score:2)

              by SQLGuru ( 980662 )

              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)

                by t0y ( 700664 )
                I agree with you.
                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.

        • 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.

          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

        • 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.

      • 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!

    • 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

    • 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)

      by arth1 ( 260657 )

      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.

    • 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.

  • Kickstarted blogging platform? (Score:3)

    by Vyse of Arcadia ( 1220278 ) on Wednesday May 24, 2017 @12:55PM (#54478025)
    Why are people crowdfunding blogging platforms?

    • Re: (Score:3)

      by hmckee ( 10407 )

      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)

    by mwvdlee ( 775178 ) on Wednesday May 24, 2017 @12:58PM (#54478045) Homepage

    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.

    • 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

  • Comment removed based on user account deletion

    • 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].

      • Comment removed based on user account deletion

        • Re: (Score:2)

          by tepples ( 727027 )

          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

  • I haven't used RSS in a long time. I previously used Thunderbird to manage my RSS feeds. Are there any good RSS clients that also accept JSON feeds?

    • Re: (Score:2)

      by SQLGuru ( 980662 )

      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.

    • 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)

    by ilsaloving ( 1534307 ) on Wednesday May 24, 2017 @01:09PM (#54478169)

    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)

      by tepples ( 727027 )

      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".

      • 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

    • 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)

      by zifn4b ( 1040588 )

      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.

    • Comment removed based on user account deletion

  • Re: (Score:2)

    by dgaller ( 849242 )
    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.

    • 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)

    by grumpy-cowboy ( 4342983 ) on Wednesday May 24, 2017 @01:22PM (#54478309)

    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)

    by thewolfkin ( 2790519 ) on Wednesday May 24, 2017 @01:54PM (#54478593) Homepage Journal

    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 Twitter. Of course, I use RSS, but RSS is too nerd for the average user.
  • It's no surprise that anyone would consider re-inventing the wheel or fixing what isn't broken because you can exchange the unnecessary labor for money. Brilliant!

  • 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.

  • 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.

  • 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.

  • in favor of a human readable JSON format

    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)

    by dhasenan ( 758719 ) on Wednesday May 24, 2017 @05:13PM (#54480151)

    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.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close