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

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.

Comments

Obligatory XKCD

[ttyler]

https://xkcd.com/927/

Re:Obligatory XKCD

[Anubis IV]

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:Obligatory XKCD

[Scarred Intellect]

I share your irrational happiness, but it is together with sadness, as I wanted to post it.

Re:Obligatory XKCD

[Anonymous Coward]

Hasn't JSON been around for a while? I thought Google Reader was able to use that format.

Re:Obligatory XKCD

[chispito]

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:Obligatory XKCD

[DontBeAMoran]

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:Obligatory XKCD

[Anonymous Coward]

I'm going to create a new standard meme. With hookers. And blackjack. You know what, forget the standard meme.

Re:Obligatory XKCD

[Anonymous Coward]

That's interesting, but I feel that there's only one particular XKCD that *really* gets to the nub of this situation.

Re:Obligatory XKCD

[Anonymous Coward]

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

Which was the point of Atom:

* https://en.wikipedia.org/wiki/Atom_(standard)

Of course JSON is the new hotness, so there's that.

Re:Obligatory XKCD

[Anonymous Coward]

JavaScript Object Notation would also seem like a better choice imho it is more kiss. Not that there is that much in it.

Re:Obligatory XKCD

[Mozai]

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.

Re:Obligatory XKCD

[hcs_$reboot]

Of course. But UTF8 is taking the lead among the encodings, for instance, because it has a lot of merits. And regarding this specific subject, I find a JSON string easier to read than a heavy XML, for instance, and each time JSON is chosen over almost anything else, I say "bravo!".

Re:Obligatory XKCD

[Big Hairy Ian]

What has the new /. overlord got against RSS

Name it J-a-SON Bateman and you'll have my vote

[JoeyRox]

Fantastic actor.

Re:Name it J-a-SON Bateman and you'll have my vote

[Anonymous Coward]

Needs to not wear watches so much. Who wears watches in this day and age?

Re:Name it J-a-SON Bateman and you'll have my vote

[tepples]

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:Name it J-a-SON Bateman and you'll have my vote

[fluffernutter]

Because when I take my watch off, I look at my bear wrist for the time all time time. That gets annoying, so I put on a watch! A watch is always on my body, a phone isn't.

Re:Name it J-a-SON Bateman and you'll have my vote

[DontBeAMoran]

But in reality, a watch is quite impractical because the time gets all blurry from the motion of your wrist when you masturbate.

Re:Name it J-a-SON Bateman and you'll have my vote

[Anonymous Coward]

I don't have time to watch my wrist when I masturbate.

Re:Name it J-a-SON Bateman and you'll have my vote

[Oswald McWeany]

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:Name it J-a-SON Bateman and you'll have my vote

[HornWumpus]

You don't own a real Rolex?

Re:Name it J-a-SON Bateman and you'll have my vote

[DontBeAMoran]

Ah yes, a Viagra joke, implying that I am old and need such a thing. Well played.

Re:Name it J-a-SON Bateman and you'll have my vote

[Darinbob]

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:Name it J-a-SON Bateman and you'll have my vote

[Hognoxious]

I look
               
...
       
...
       
...
at my bear wrist

Ah, that explains the long paws.

I like XML better

[Anonymous Coward]

XML > JSON

Re:I like XML better

[__aaclcg7560]

I like XML too. But only because I had to write an XML parser from scratch in Java as my final project before graduating from college. That level of detail tends to stick in your head.

Re: I like XML better

[Anonymous Coward]

An XML parser was your final college project? No wonder new grads are so worthless on average...projects that promote silly busy work and ignore libraries dedicated to the task.

Re: I like XML better

[Anonymous Coward]

You gotta remember though that this was after the govt gave everyone money to goto college. In the early 2000s Creimer got a free education. Creimer and I graduated together. He's a scumbag, nah I'm just kidding, he's a great person.

xD

Re: I like XML better

[Anonymous Coward]

Damned if you do, damned if you don't. People need to learn basics, and part of that is knowing that the tools you use every day, didn't just grow out of nothing; people had to make them.

Way back in the day, I had a data structures class where we used Fortran 77, and in the end we were basically writing malloc() for arrays of integers. Why? Because it was (almost) the worst-possible language for the job. That's not a joke. F77 was chosen so that you would have to create the fundamental building blocks.

You don't want a sword. You want your dwarves to mine iron and cut down trees for fuel and make steel and pound the billets into an axe head. It's the journey, not the destination.

Or at least in a class. C'mon, a class! Your grads can still use libraries, but now they know how to make libraries too, if they need to. People need to know how stuff works.

Re: I like XML better

[__aaclcg7560]

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: I like XML better

[fisted]

You seriously need to stop replying to this.

Re: I like XML better

[TheRaven64]

Spoke like someone who has never read the XML spec. If it correctly handled XML namespaces, I'd be happy with it as an undergraduate project. It's trivial to write something that will handle 90% of valid XML. The remaining 10% is really hard!

Re: I like XML better

[__aaclcg7560]

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: I like XML better

[DontBeAMoran]

People need to know how stuff works.

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: I like XML better

[HornWumpus]

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: I like XML better

[__aaclcg7560]

Otherwise we get "web monkeys" who load jQuery before writing a single HTML tag [...]

How do you load jQuery without writing a script tag?

<head>
<script src="jquery-3.2.1.min.js"></script>
</head>

https://www.w3schools.com/jquery/jquery_get_started.asp

Re: I like XML better

[__aaclcg7560]

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

Re: I like XML better

[jeremyp]

Yes because everybody knows he could have used a regular expression.

Re:I like XML better

[ArchieBunker]

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: I like XML better

[__aaclcg7560]

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:I like XML better

[Anonymous Coward]

The intent at one point was for an XML-compatible version of HTML- known as XHTML- to take over as the standard. It was- I assume- thought that having HTML be able to be handled by the XML libraries and tools coming onto the market would be beneficial.

For various reasons, this was ultimately rejected, and XHTML has been sidelined into being just a serialization option for regular HTML, with the non-XML-compatible HTML5 taking over instead.

Re: I like XML better

[Anonymous Coward]

My, aren't you a hoot and a holler.

Re:I like XML better

[Anonymous Coward]

My main exposure to XML files has them being used for configuration settings instead of INI type files. IP phones, switches, terminal servers, and probably routers are using them. The Cisco Finesse web site on Contact Center uses XML to configure dashboards.

Re:I like XML better

[Anonymous Coward]

What is XML even used for? Seriously, wasn't it supposed to overtake HTML at one point? Who uses it and for what purpose?

God damn, that's a rather embarrassing and revealing remark to make on a technology website. What are you doing here?

Re:I like XML better

[K. S. Kyosuke]

SEXP > XML > JSON

Re:I like XML better

[Narcocide]

I just thought it was funny how they implied JSON was somehow more human-readable and less prone to parsing errors, as though they hadn't actually ever tried doing this with XML to see.

Re:I like XML better

[K. S. Kyosuke]

It's a good remark. Quoting a paper on that matter, "the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."

Re:I like XML better

[Lord Crc]

What is XML even used for?

We use it a lot for data exchange with various other systems. Most systems we talk to have moved away from fixed-width, comma-separated or EDIFACT files to XML.

Of course, frequently the XML files we get has clearly been generated by a bunch of printf()'s with all the specification-breaking stuff that can lead to. Still, it's nicer to work with than fixed-width or comma-separated files, and easier for humans to read and manipulate than EDIFACT.

Re:I like XML better

[goose-incarnated]

I like XML too. But only because I had to write an XML parser from scratch in Java as my final project before graduating from college. That level of detail tends to stick in your head.

XML Parser as a graduation project? I wrote one in ANSI-C hosted over a drunken weekend during my third divorce. I believe it's still used on some backend BSD system somewhere.

Re: I like XML better

[goose-incarnated]

Yes because everybody knows he could have used a regular expression.

I don't recall using regex for my XML parser in Java.

I don't think you can. XML is not a regular language.

Re:I like XML better

[Big Hairy Ian]

Lets make this clear for everyone

XML == W3C Standard and is based on SGML as is HTML

JSON != W3C Standard

Both can easily be cocked up by improper implementations

Re: I like XML better

[Anonymous Coward]

-1, w3schools considered harmful.

Bad reason

[mi]

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.

Re:Bad reason

[CastrTroy]

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

[bill_mcgonigle]

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

[Anubis IV]

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 find it rather unfortunate that they named it "JSON Feed" because it obfuscates the fact that the most important changes aren't about the switch to JSON, but are rather about the ways in which they're using it.

Re:Bad reason

[Anonymous Coward]

>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.
The spec and libraries are easier to understand for JSON rather than XML. Those reasons alone are why there will be less malformed JSON.
XML needs to die as the common go-to interchange format.

Re:Bad reason

[Anonymous Coward]

I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.

I'd agree, except for one thing:

JSON disallows comments.

This makes it TERRIBLE for a human-readable data format. It's great for dealing with sending data to JavaScript (because it is, after all, JavaScript), but it's absolutely terrible for storing data in a human-readable format.

I'd much prefer YAML over JSON because YAML DOES allow comments.

Re:Bad reason

[KiloByte]

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 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:Bad reason

[tepples]

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:Bad reason

[HornWumpus]

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:Bad reason

[AuMatar]

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:Bad reason

[Anonymous Coward]

If you store natively json, than it is probably more efficient to send this to the client browser as json. Why introduce specialized conversion if not needed.

Re:Bad reason

[HornWumpus]

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 XML, don't roll your own.

Re:Bad reason

[SQLGuru]

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:Bad reason

[HornWumpus]

Java is the one true language...apparently. Some people never learn.

Re:Bad reason

[cjjjer]

I agree lets just stop using all of this ridiculous markup language once and f

Re:Bad reason

[arth1]

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:Bad reason

[coastwalker]

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:Bad reason

[organgtool]

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:Bad reason

[t0y]

Way ahead of you: http://json-schema.org/
I'm sure there's a xslt equivalent somewhere.

Re:Bad reason

[Anonymous Coward]

XML is not difficult to parse. Not only that, but XSDs can be used for validation. XSLT can be used to transform it into HTML. Want to add something custom? Namespaces are there to help so that your "rating" tag doesn't clash with someone else's "rating" tag, for example.

XML can be a bit verbose, it is true, and it may be overkill for something simple like RSS, but at the same time what we have works and it works well. I don't see a compelling reason to move from XML to JSON here.

Is there a real problem in the RSS world that I'm unaware of? Or is this just change for the sake of change? Sounds like the latter.

Re:Bad reason

[SQLGuru]

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:Bad reason

[Anonymous Coward]

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

But most importantly, do you use tabs or spaces?

Re:Bad reason

[Wootery]

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:Bad reason

[maestroX]

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 properly, because there's no semantic description and everyone abuses the schema to their own end, so why not pick the far more efficient format in the beginning?
Worked at a large hotel booking site, moving from XML (the "standard") to JSON (with rewriting on our account) saved and saves lots of manhours, performance and data transmission.

Re:Bad reason

[maestroX]

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 like Postscripting vs. html.

Re:Bad reason

[t0y]

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.

Re:Bad reason

[Darinbob]

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 time to complete the feature without ever feeling rushed).

JSON as a standard is very weak. It's hard to find a well defined specification suitable for implementing. There are a lot of assumptions made. Ie, how do you store binary data? Normally base64 but nothing requires this or specifies what base64 is and how it must be represented and what to do with the leftover odd bytes at the end. But everyone sort of knows as vague tribal knowledge what to do (do what Javascript does, do it the same way Python library does it, etc). It's a simple format, it has much going for it, but it's not formally specified.

Re:Bad reason

[Darinbob]

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:Bad reason

[Darinbob]

Yes, I found that when I needed to do JSON parsing that it was vaguely defined. You need to know other stuff before you can proceed, which is why I really hesitate to call it a standard because so much is missing in the very short specification I read. The specification does say reasonably clearly how to parse, but not how to interpret the data that gets parsed. The stuff you need to know is that this is Javascript code compatible, thus the data types are the same as they are in Javascript, and strings can be used to encode binary data using base64, etc. Also imagine that there is an implicit "{" and "}" surrounding all of it.

Re:Bad reason

[Anonymous Coward]

Why do you have to roll your own when there are already libraries for it. Duh

Re:Bad reason

[Anonymous Coward]

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.

An XML schema can do some truly amazing input validation. It is great for inter-op if you have someone defining the spec and forcing everyone to stick to it. The best thing about all that amazing input validation is you don't have to code any business logic to get it.

JSON, from what I've seen, is just great for painless interop, and as long as the same engineer or engineers are controlling all the tools that consume or produce it, all is well. Hell, I wouldn't be surprised if someone wrote a JSON parser for ADA. Its ubiquitous. Need to configure a big binary blob of C? Pass along some big JSON strings and be done with it. If you start with C# you can probably use something like Newtonsoft to convert bits of XML to JSON.

I'm still wary about using JSON for a configuration document. If I have the choice, I want the extra benefit of a very detailed schema, although as someone mentioned that is coming for json. Personally, I also find XML more readable. Seriously, if you want compact you can just do:

Actually, at this point I'd come close to just using sqlite files before I went to json for an editable file. its also available pretty much everywhere, and it takes little time to just get to work with it.

If I had to put less structured data in a DB, I'd probably use JSON though. Compactness wins there. Of course you try to make tables and such to not have to do that. Still, even if you did, I believe microsoft and one or two others can query JSON fields, and a database like H2 would just allow you to write a database alias that calls a java function to do whatever you needed to do.

BTW, while I'm hardly a database master, Java's H2 database with its integrated query interface is great. Start up your ap, then you get a link you can open in any old web browser to see what is going on...

So in short, JSON wins sometimes... It is yet another tool in the toolbox...

Re:Bad reason

[Anonymous Coward]

I agree, that JSON is easier to read than XML

Is it really though? Is there something special about angle brackets that makes them more difficult to read than curly braces, square brackets and commas?

JSON is more concise, but in real world situations where nesting becomes deep and content long, I find having the closing tag explicitly state what is being closed helps rather than hinders readability, and for parsing, it helps to detect the malformed markup so it can be ignored/flagged instead of producing confusing garbage output because a curly brace was switched with a comma somewhere.

Re:Bad reason

[Anonymous Coward]

I agree lets just warning: unreachable content after end of markup

FTFY

Re:Bad reason

[Anonymous Coward]

My impression of JSON is that it's a deeply nested hash of hashes (or arrays).

Your standard complex data structure found in a dynamic language, that is.

Compared to XML, it lacks tag attributes and... Well, not much else.

The irritating part about JSON is that the instances of it I've seen online never seem to have a line break anywhere.

JSON is just XML from the Java ecosystem.

I really don't get what you mean by that. The Java ecosystem already has an XML: It's called XML.

The JavaScript ecosystem is what JSON came from.

Re:Bad reason

[Dog-Cow]

You must be a pretty stupid person if those things confuse you. [ is for arrays, { is for dictionaries. Trivial. Spaces are never significant, though they are preserved within strings. Quotes are necessary to quote things, like strings. Otherwise, they aren't. Gosh, that was hard. I have never seen a | used in JSON, so I don't have a clue what you're on about. Also, semicolons are not used in JSON.

If you're a programmer, none of this is hard. The syntax is far simpler than even the simplest scripting languages in wide use.

Re:Bad reason

[yurikhan]

> how do you store binary data?

You don’t.

Seriously, there is not much reason to want to store binary data in JSON. As a minimum, you want to tag that blob with a MIME type, so that other code will know what to do with it. And as soon as you do, you can represent that with a data: URI. Which gives you a choice of two serialization modes, quoted-printable and base64, both well specified and documented.

Re:Bad reason

[yurikhan]

The problem with RSS/Atom is not in the XML. It is in the HTML that is embedded within.

RSS was not designed for content to be embedded in it. It had a short-plain-text-only element. People started putting HTML in there. It broke XML structure. People started escaping that HTML. RSS 2.0 made that practice official.

The designers of Atom looked at RSS and saw that it was bad. They added an element for the content and specified that it can contain plain text, escaped HTML, or include XHTML as a sub-schema. The intent was, probably, that all good people will write valid HTML and serialize it as XHTML. It never took off. People are still writing invalid HTML and escape it in their feeds.

And that is the problem. People who are likely to write blogs are also likely to write invalid HTML. That is a basic fact and cannot be changed by choosing a different container.

Re:Bad reason

[yurikhan]

Bullshit. XML *is* part of the Java ecosystem. JSON is from Javascript which is an entirely different thing.

Re:Bad reason

[yurikhan]

Using a library does not solve the problem of designing a schema, which is what the “property or data” question is all about.

Re:Bad reason

[Darinbob]

This was for a device not the web, and I needed the binary data. It was only used as key/value holders, no such thing as URI or MIME exists on the system. There was no need for JSON but someone felt it was more "standard" than a different protocol we had been using. Thy syntax was the only specification I could find at the time, no description of how to specify something other than numbers or strings. On hindsight I probably could have just looked at some Javascript documentation.

Re:Bad reason

[yurikhan]

+1 on comments. -1 on YAML.

YAML tries to be human-readable and human-writable. Fails on that point. Has as many as five different syntax for string values (double-quoted, single-quoted, unquoted; folded blocks and literal blocks). Even glancing through the YAML spec to find the above information gave me a headache.

Re:Bad reason

[yurikhan]

Well, that was your problem: Using a text-based container where you are only interested in binary payload. You get all the cost (parsing time and complexity) with none of the benefits (readability).

If that binary is a byte-by-byte representation of some data structure, you could have represented each member of the structure as a JSON object property. No need for binary.

If that binary is just a byte array, you could also use arrays of numbers. Not a very tight encoding, though — 2 to 4 JSON characters per byte of payload.

What you could not do, though, is treat a byte array as a string.

Anyway, what you lacked was not a well-defined specification; JSON is quite well defined. You lacked usage guidelines.

Re:Bad reason

[AuMatar]

How does a library help to define whether something should be a property of a tag or data held within it (not discussing embedded tags, but embedded strings/numbers/values). XML has 2 disjoint ways to embed data, with no real reason to have two or to use one over the other. Json doesn't. That's the property/data issue, and its a major usability issue with XML.

ANd no, XML is nowhere near as tight. Comparing properly printed and spaced xml and json, json is always more readable. XML is overly verbose and harder to see the structure. Particularly its harder to find arrays.

Re:Bad reason

[alexgieg]

Yeah, what is the _actual_ problem that RSS/Atom are causing now?

According John Gruber from Daring Fireball, JSON feeds seem to solve three (minor) issues: first and foremost (for him), it's very, very easy, and very fun, to implement by oneself, so any app developer can add support to it to their apps in a matter of minutes. Second, it allows you to provide two canonical URLs for an entry, one for your own website's post, one for something else, which in his case is the article he's commenting about (his blog is built around short comments to bigger articles), so that feed readers can show both in a distinctive way. Third, it's easily human readable when opened in a simple text editor.

Those are valid points. They might not be important points or anything more serious, but they're valid for those who like to do things that way.

Kickstarted blogging platform?

[Vyse of Arcadia]

Why are people crowdfunding blogging platforms?

Re:Kickstarted blogging platform?

[hmckee]

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 social media sites irrelevant.

Re:Kickstarted blogging platform?

[Anonymous Coward]

You must not have checked it out very well. The crowdfund is for the guy to write a book about it.

For the record, there are already dozens of FLOSS microblogging platforms and most of them have some level of compatibility with each other.

There are also a half-dozen FLOSS blogging platforms, also somewhat compatible, at least for the very few types of posts that the silos have. It isn't hard to replace their crappy software, silos are mostly useless except to mine private data and accrete new victims^H^H^H^H^H^H^Hcustomers which is the precise thing they were designed for.

Frequently malformed XML??

[Anonymous Coward]

I've certainly seen lots of malformed json as well.

And frankly, there are libraries to correctly build & sanitize the contents of both XML and json, so there is no excuse for that - it tends to be developers who try to roll their own and reinvent the wheel badly.

Re:Frequently malformed XML??

[tepples]

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.

Re:Frequently malformed XML??

[mrbester]

There's no such thing as malformed JSON. It is either JSON or it is some garbled hot mess that needs hacky shit to parse.

Re:Frequently malformed XML??

[Anonymous Coward]

JSON by design is a garbled hot mess that needs hacky shit to parse. So malformed JSON would be readable.

Obvious solution

[mwvdlee]

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:Obvious solution

[Anubis IV]

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 solution, which is why they had to create the new format to address those issues, among many other ones. Once you realize that fact, basing it on JSON or something else simply makes sense, what with it having far simpler and more ubiquitous library support in the software stacks involved, which is in addition to it being simpler to read and write.

Re:Obvious solution

[Anonymous Coward]

Wasn't XML supposed to be, oh, eXtensible?

Re:Obvious solution

[Anonymous Coward]

Problem: Duplicate entries frequently appear in feed clients.

That's an implementation problem. If server-side, the server should not be compiling RSS with duplicate entries, and a check needs to be implemented in the logic there. If client-side, the client should be smart enough to look at its stored database and new feed to detect things like URLs that haven't changed. Again, logic, but not a model problem. The XML format does not have a problem there.

Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.

Do people actually read that old content, or is it just cruft? Maybe you shouldn't still be serving articles from 1995 in your RSS feed. Maybe you should think about limiting things. That doesn't mean the model is broken, just your sense of how important your content actually is.

Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.

Finding favicons has never been a problem for me. I don't consider that a problem. Perhaps someone else does. Sounds like it's easy to solve, too, since favicons have a predefined place to exist on a server. Images and enclosures are often spelled out in the RSS feed item's body. This has never been a problem either.

I wonder if the real purpose behind this isn't to enable ads and analytics in feeds.

Re:Obvious solution

[Anonymous Coward]

solution B

B. By by very very very far !!!!!

Lets consider XML as binary is you are too... hum... [place anything here]. Maybe dont like when TL;DR

No one write syndication by hand. Dont be shame, I help you if you do.

Is there any programmer here? Do you have a new product to market? C'mon pity.

Consider XML as binary, dont need to learn anything else...

Re:Obvious solution

[Anubis IV]

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 duplicates. I probably see this happen once a week with Slashdot's feed alone.

B) Yes, people read old content. I can't count how many times I've started reading a webcomic years after it launched and wished that I was able to go back to the start in the feed, since it'd make it easier to track my position. Allowing pagination enables them to make it possible for people like me to go back through their content as far as we want.

C) While favicons are usually at the root as a matter of convention, the correct way to specify their location is through the use of <link rel="shortcut icon"/> in the head of a page. Because that's not part of the RSS spec, clients are left to themselves to try to find the favicon, either by hoping it's at root or by scraping the site to see if it specifies the location via a link tag. I used to run a very modest site that published an RSS feed, and I can't count how many requests I got for a favicon that didn't exist from RSS clients trying to find it.

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.

Re:Obvious solution

[Anubis IV]

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:Obvious solution

[chispito]

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: Obvious solution

[Anonymous Coward]

*cough*Atom*cough*

Re: Obvious solution

[Anubis IV]

Atom only fixes the first problem I listed, so far as I know. If I'm mistaken, feel free to correct me.

Re:Obvious solution

[Anonymous Coward]

Problem: Duplicate entries frequently appear in feed clients.

<atom:id>

Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.

<atom:link rel="next">, etc.

Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.

<atom:link rel="icon">, etc.

Re:Obvious solution

[Anonymous Coward]

We need to keep the former so the user can read them

No, you don't. If the entry was removed, the user does not need to see the entry. An RSS file originally was XML that could be XSL'd into a web page for human display: that would show no removed entries, and that's on purpose. If an article has been removed from the RSS stream, the author does not want you reading it. If you need an archive of every post made from some site, RSS was never the right tool for you, JSON Feed probably isn't either, and you probably ought to question why you need an archive of every post from someone else's site in the first place.

Re:Obvious solution

[Graymalkin]

Problem: Duplicate entries frequently appear in feed clients.

This is entirely the fault of the client software and rarely the fault of the feed producer. Even if it is the fault of the feed producer it's the sort of problem they'll have with JSON feeds.

Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.

In what way do you think that serving up old content via JSON will be less expensive than via RSS. There will be fewer characters representing tags and such but that's not so big of a difference as to automatically make JSON better. Compressing the feed is going to largely solve the issue of file size between the two formats.

Besides RSS is not really what I would expect a site to use to provide links to their historical pages. That's the job of a sitemap (XML, HTML, or whatever) or possibly OPML. Someone looking for historical links isn't necessarily looking for the syndication features of RSS but instead just a list of links that they will go and spider themselves.

Neither RSS or JSON is really appropriate to provide clients with the entirety of a site's historical content.

Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.

This just doesn't make sense. RSS and Atom both have rel property support in tags. So it's trivial for the client to discover supplementary resources for an article. If a producer is not going to include those things in their RSS feed they're not necessarily going to include them in their JSON feeds either. The "Extensible" portion of XML allows producers to add all the extra tags or properties they want as clients will only pay attention to the ones they actually use.

None of the issues you listed are actually issues. Beyond that bad XML produced by whomever is much easier to fix than adopting yet another "standard" only supported by some small fraction of devices on the web. XML's been around a long time and is pretty boring so I don't know what software stacks you think don't have XML support built in. Most stacks likely have fairly robust XML processing capabilities like validation and transforms beyond just deserialization.

Re:Obvious solution

[Anonymous Coward]

Problem: Duplicate entries frequently appear in feed clients.

Not going to be magically solved by failing to use unique guids in JSON instead of failing to use unique guids in XML.

Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.

Not going to be solved by shaving a few bytes off the closing tag and putting them back elsewhere as double quotes and commas.

Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.

Not going to be solved by failing to encode them in JSON instead of failing to include image links in RSS or Atom.

Re:Obvious solution

[UnderCoverPenguin]

I wonder if the real purpose behind this isn't to enable ads and analytics in feeds.

I have seen ads in RSS feeds. I'd be surprized if there weren't analytics.

Just like...

[freeze128]

IPv6 anyone?

Re:Just like...

[unixisc]

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?

Really? Biased much?

[Anonymous Coward]

" in favor of a human readable JSON format" - ? Sure with hundreds of thousands of open braces and brackets and undefined tags, right... I propose we improve this by using human readable text files for feeds. Just straight old readable text. As the population gets stupider, simplistic structures like XML are impossible to use!

"something interesting" + "world of news feed"

[CustomSolvers2]

Only in Slashdot! Is this something to be proud or ashamed of? LOL

I developed a small application to check some sites regularly and discovered that there are quite a few posting lots of information which don't have any (RSS) feeds. I also found the feeds in some of them either horribly formatted or with faulty/delayed data?! Most of nowadays websites are dynamically generated and adding just one tiny layer of automation seems pretty straightforward, how can be this possible?

Regarding the JSON format, I honestly don't care. Once you have the generation/retrieval algorithm, dealing with one or other format is very easy. All what I want is having something in place at all!

Are there any good RSS client out there...

[__aaclcg7560]

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:Are there any good RSS client out there...

[SQLGuru]

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:Are there any good RSS client out there...

[Anubis IV]

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.

Re:Are there any good RSS client out there...

[Anonymous Coward]

I don't know - are there?

Re:Are there any good RSS client out there...

[dgaller]

I like Tiny Tiny RSS, though it's web based so you need to run your own instance or pay a host.

YAML FTW

[Anonymous Coward]

Why stop at JSON? Its parsers are too fast, let's use YAML.

Oh FFS

[ilsaloving]

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:Oh FFS

[tepples]

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:Oh FFS

[Anonymous Coward]

but everyone thinks it's great cause it's new and cool, and XML sucks because it's "old".

Nuts to that. I hated XML back when it was new too.

Re:Oh FFS

[HornWumpus]

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:Oh FFS

[Anonymous Coward]

Ever heard of Json Schema ?

Re:Oh FFS

[Anonymous Coward]

There are limitations in all XML schemas. Best I can tell, they are inherent to the nature of a scema validation. But... they still have plenty of utility. Also schemas were semi-common. When working with XML, I didn't always get a schema but I often did. With JSON, I have yet to see JSON validation being common. I've also seen plenty of JSON mistakes that would have been caught with XML using a XML schema.

So yeah, switching to JSON does actually loose some nice things of XML. That isn't to say JSON isn't good or shouldn't be used, but it isn't objectively better than XML and misses out on some XML features in very practical ways.

Re:Oh FFS

[tepples]

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.

Re:Oh FFS

[ilsaloving]

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/

Re:Oh FFS

[ilsaloving]

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 to fill in that gap (http://json-schema.org/), but without something directly in the JSON spec, there best you can hope for are non-standard cobbled together solutions like the above.

Re:Oh FFS

[zifn4b]

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 then? Eagerly awaiting your informed and educated response.

Re:Oh FFS

[zifn4b]

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/

Translation: I don't really know what the fuck I'm talking about and I want to back-pedal gracefully soas not to get my ego bruised too much resulting in butt hurt. Next time, before you open your mouth, do a Google search.

Re:Oh FFS

[zifn4b]

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:Oh FFS

[Anonymous Coward]

This is exactly the point and the fondation of XML.

Sloppy and writing easier in JSON in a text editor. That is not useful for programs.

If you implements a protocol, its programmatic you dont help your programs with JSON.

It is more difficult to interpret human fog.

Re:Oh FFS

[squiggleslash]

There never has been a time when everyone was all "Oooh oooh! Our solution will be so much better if we USE XML!!!11!eleventy". XML has always been exceptionally unpopular with actual developers, it's always been PHBs and the computing community's equivalent of Very Serious People that has forced that god-awful standard on everyone.

Developers have always been trying to come up with better alternatives ever since XML was foisted upon us. It's taken a while, JSON took off because every implementation of Javascript has a parser (and had one before JSON was invented), but it wasn't the first, just the first that was so popular amongst developers that the VSPs had to throw their hands in the air and admit defeat.

Re: Oh FFS

[Anonymous Coward]

No, and neither has anyone else, so it may as well not exist.

Re:Oh FFS

[Anonymous Coward]

I for one am glad for schema not being a requirement. Schema's are a far more hindrance in the real world than they actually help.

Although its nice, now you have a validator that checks everything, but now that it checks EVERYTHING. A simple program to process parts of it, now has to validate the whole document, and consume a lot of unneeded cycles validating data you will never work with.

I've done several tests on the differences. On average, I've found most XML documents contain 30% more "junk" than JSON, this affects all kinds of things, like transfer speeds/data, parsing CPU usage for a longer string, storage consideration for millions of documents. The C/C++ libraries that almost every software languages use, under linux its 1.5Megs for XML, and 22k for JSON. It shows that there is far more code in an XML parsing library than a JSON one, which as i've found a ~300% increase in the time it takes to parse an XML document than a JSON one, and thats with NO schema validation. Add that in and its around 500%. Also, while in memory, XML takes an average about ~80% more memory for the same exact data. In the time it takes to process an XML document, I can process HUNDREDS of JSON documents. I have a webdav that I connect to with a directory of ~20000 files. I copied the xml document and converted it to an equiv JSON, then I just had 2 scripts that loaded the document and just held it. The XML script was using 1.5Gigs of RAM for that document, and JSON document was around 600 megs.

XML also gets far too abused by standards committees. vs test vs test and sometimes they are intermingled in the same document!

I also did a test by writing my own JSON parser and adding my own features. Took me literally 2.5 hours, fully compliant to the spec, with some added features like allowing single quotes, unquoted object keys, and a file include feature {"data": @"includefile.json"}.

Personally, I've loved JSON since its inception, and I use it for a lot of non javascript projects. I.E. I have several C/C++ applications that use it as a configuration file. The benefits of using it over XML is far reaching. And as long as they don't allow code, or psuedocode into the standard, I believe it will stay pretty awesome for a while.

Re:Oh FFS

[ilsaloving]

Translation: I'm an asshole who doesn't have anything constructive to offer, so I'm just going to be a shit disturber instead.

If you honestly think that some homebrew library is equivalent to a formal validation process that is part of an industry-wide spec, your the one who doesn't know what the fuck their talking about.

Now go back to your mom's basement and let us adults talk.

Re:Oh FFS

[ilsaloving]

You'd be surprised. There were actually a lot of people going on about how great XML ones, both business people and developers alike. I was talking to a coworker recently, and he told me a story where a client actually leaned forward and excitedly asked, "Will your solution have XML?"

Just thinking about it gives me Forrest Whittaker eye.

human readable JSON

[Anonymous Coward]

What the heck is the point of human readable, when anyone sane is going to be viewing through a viewer that re-formats it anyways?
If this is going to be successful, no one is going to be hand writing the JSON anyways but rather using some editor, and no viewer is going to be examining the raw JSON. It might as well be a binary blob for all anyone cares.

Re:

[dgaller]

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.

YAML

[tepples]

I propose we improve this by using human readable text files for feeds. Just straight old readable text.

Something like YAML, a more "human-readable" serialization intended to fill some of JSON's niche?

Harder to malform the JSON

[SuperKendall]

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, that's to be sure.

Why, when most JSON will be produced by a library that simply maps something out to JSON? Also it's super easy to check JSON validity. If you ask 100 developers today to produce a defined output in JSON and XML, which do you think will have a much higher percentage chance of being correct?

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?

Why do you think any of that matters? If the JSON is valid it is valid. Everyone on earth and most libraries are used to accommodating JSON that may have true or false either as boolean values or as strings for example. It simply doesn't matter.

I agree, that JSON is easier to read than XML, but not easier enough

It's WAY easier to generate in a world of developers that uses mostly JSON now and hardly touches XML. That alone is a HUGE reason to switch. Why saddle every website on earth with legacy crap? It's probably a big part of the reason RSS is not as common anymore, and the real crime would be if most sites had nothing like RSS at all...

Re:Harder to malform the JSON

[CustomSolvers2]

The latest .NET versions are also moving to JSON.

Re:Harder to malform the JSON

[dbrueck]

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 popular for client-server communication on the web.

Re:Harder to malform the JSON

[Anonymous Coward]

The J in JSON literally stands for Java.

It's JavaScript Object Notation.

Now, granted, JavaScript is totally unrelated to Java. Well, sort of: Java now comes with a JavaScript interpreter. Because the Java standard library wasn't already bloated enough. Best of all, though, because it's Java, it attempts to abstract the JavaScript interpreter to the point that it could be any language, making using it basically useless.

Hilariously, although Java comes with an entire JavaScript interpreter, it does NOT come with a JSON parser. That requires external libraries.

Re:Harder to malform the JSON

[gnunick]

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:Harder to malform the JSON

[dbrueck]

LOL, nice trolling - well played. Have a great day!

Re:Harder to malform the JSON

[worf_mo]

Um, you do know that the 'J' in JSON doesn't stand for 'Java', right?

You woke my nitpick mode: The J in JSON literally stands for Java (and the S for Script).
I agree with the rest of your post, though.

Re:Harder to malform the JSON

[Anonymous Coward]

Eh, that's naive.

I work with XML all day, every day. The amount of malformed xml and inconsistencies is frustrating enough to where some of my xml sources I have built a pre-parser that massages the data before I even introduce it to the commercial parser my company uses that can't handle shit like ISO character sets (this has since been fixed, but it was a pain 5 years ago). Stuff like not escaping a fucking ampersand correctly. Or quotes. And these are systems that have been in place for a decade+, with numerous requests for fixes, etc. As much as I'd love to just turn off the switch and say "Okay, assholes, either you fix your shit or we don't use your content", unfortunately, we're just a small fish and they don't a fuck and my bosses say its easier to just pay me to fix that shit on our end.

The fuck. The point is, yes, the xml ecosystem should be nice and robust and well mannered and yet, here in 20fucking17 I'm still seeing shit come through that is complete bullshit. Hell, it's my *full time job* to deal with this garbage. "Why the fuck did that xml fail parsing?" Open xml. "What the fuck is that fucking shit? Who the fuck.. What the fuck.. sigh." *write another detection/handling case* *get paid*

 

Re:Harder to malform the JSON

[James Carnley]

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:Harder to malform the JSON

[Anonymous Coward]

Silly. worf_mo was not saying Java and Javascript are not distinct words. J in JSON indeed literally stands for "Java"

Re:Harder to malform the JSON

[Anonymous Coward]

JSON is vastly simpler, maps easily to the most common data types, and is (get this...) usually easy (for humans) to read.

And it would be a lot easier for humans to read if it had goddamn linebreaks.

I mean, it has goddamn linebreaks but nobody seems to be outputting them.

Who wants to read a 1000-byte nested hash on a single line, with no spaces anywhere?

Re:Harder to malform the JSON

[gnunick]

And it would be a lot easier for humans to read if it had goddamn linebreaks.

I mean, it has goddamn linebreaks but nobody seems to be outputting them.

Who wants to read a 1000-byte nested hash on a single line, with no spaces anywhere?

Well, given the choice of XML with no linebreaks, or JSON with no linebreaks, which one would you pick--honestly?

But of course, linebreaks are allowed in JSON, and (IMHO) should be included in almost any JSON written to any file. But with data serialized over the wire (i.e. to/from a web browser), linebreaks add bytes but no real value. I don't know of any web browser that doesn't have tools that allow you to easily browse the entire data structure.

Re:Harder to malform the JSON

[codeButcher]

Thank you!

I've recently done a project where our (new) Angular2 front-end was supposed to get data from (somewhat oldish) SOAP web services. (For those not up to date, SOAP came from the era when XML was all the rage, so guess what the requests and responses contain - yes XML.)

(I'm not sure if Angular2 is really the next thing or just a fad, but hey, it puts bread on the table. And seems to work for Google - e.g. Gmail's web interface.)

Calling REST web services that produce JSON, and consuming that JSON in the tech's underlying JavaScript is a no-brainer and is done with the built-in JSON.parse()/.stringify() methods. Converting the XML returned from SOAP web services to something usable is quite a bit more involved. Not least of all because it seems that there are again a couple of competing conventions for doing it "properly". And you will either need some library, or even worse roll your own. Also seems that parsing the more character-rich XML might be a bit slower, although I have no first-hand comparison data.

But hey, whatever puts bread on the table.

Re:Harder to malform the JSON

[gnunick]

I've recently done a project where our (new) Angular2 front-end was supposed to get data from (somewhat oldish) SOAP web services. (For those not up to date, SOAP came from the era when XML was all the rage, so guess what the requests and responses contain - yes XML.)

So sorry! SOAP is dirty, disgusting and should be flushed down the drain. ;-)

Unfortunately SOAP and XML are part of my current day job--but as you say, it puts bread (etc.) on the table.

It's about ads

[tepples]

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.

Re:It's about ads

[CustomSolvers2]

You might be right, but I don't think that any of this beneficial to them.

People willing to download an app or only interested in visiting the site will probably do that right away. On the other hand, those looking for feeds and not finding them might get a bad impression and even stop using it completely. 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.

Re:It's about ads

[tepples]

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 need to either somehow encourage viewers to pay or go out of business.

So is this a business or a charity?

Re:It's about ads

[CustomSolvers2]

So is this a business or a charity?

Nothing to do with charity, but with doing what is best for your business in the long term. If you are already posting the information publicly, everyone could get it automatically without you adding feeds (they could directly parse your web pages). The feeds aren't giving away anything, but showing a caring, adaptable and even professional attitude which you customers will always prefer over restrictions.

Let's say that you expect 100 visitors, out of them, 65 will only use the easiest alternative without caring about advertisements or downloading your app. Other 20 try to get the feeds once, don't like the result and start using the easiest alternatives. But then you have a minority (15) who will not like at all your attitude and will look for a different alternative; they might even talk bad about you and make you lose much more than what you would be earning if they would view yours ad. Proper feeds would have happy that minority (= earnings, even just via positive feedback, you wouldn't get otherwise). Perhaps, you might lose the direct benefits from the second group of 20; but on exchange, you would get something much more valuable than short-term earnings: having all your potential visitors happy and getting what they want.

Re:It's about ads

[tepples]

But then you have a minority (15) who will not like at all your attitude and will look for a different alternative; they might even talk bad about you and make you lose much more than what you would be earning if they would view yours ad.

Where has "talk[ing] bad about you" actually mattered? The 15 percent who run into problems viewing WIRED, the INQUIRER, and The Atlantic with tracking protection turned on haven't yet caused enough bad press to shut down those publications. These publications have been able to get away with not only demanding to show ads but also demanding to track the user from one site to another.

Re:It's about ads

[CustomSolvers2]

Where has "talk[ing] bad about you" actually mattered?

?! Always! Reputation is a very relevant asset for any company and being proud of having your customers unhappy is plainly stupid. With internet and how easily information is spread nowadays, this aspect has reached a new level. To not mention the fact that the opinions of the members of this small tech-savvy group are likely to be much more influential than the ones of the remaining 85.

These publications have been able to get away

Bear in mind that your links refer to something with more impact on direct ad revenue than feeds (as said, enabling them doesn't imply an immediate income lost, just proves your professionalism and proper understanding of your audience needs), but even though my ideas also apply there.

Why do you think that they did get away with it? Do you know the real impact of these critics or even what they might have indirectly provoked? You can find lots of references to managers making really stupid decisions and provoking huge loses to their companies; and each of these times, the given company didn't get away with it but plainly lost, precisely the most probable outcome of the situations which you are referring. These publications didn't comply with the (sensible) requests of part of their audience and, as a result, they didn't get the direct benefits from that minority, got bad press (whose exact impact is unpredictable, but certainly negative) and might have even suffered further losses (e.g., members of that minority stopped using/recommending that publication).

A company seriously thinking that can impose whatever to its customers and get away with it is in complete denial. Even under the most monopolistic and stupid-customer conditions, they will certainly lose sooner or later. Customers were, are and will always be the supreme rulers of companies; any business not accepting that reality or trying to somehow trick clients into believing otherwise is doomed to fail.

Re:It's about ads

[CustomSolvers2]

Correction: my starting "?! Always!..." should have been "?! Everywhere!...".

I annonce new formats...

[grumpy-cowboy]

YAML Feed
INI Feed
CSV Feed
PROTOBUF Feed
THRIFT Feed
TSV Feed
TXT Feed
{NEW TRENDY FORMAT} Feed

Noob chiming in

[Anonymous Coward]

I've read over the years that JSON data size is smaller? Also read that gzip negates this transparently. Does leveraging JSON instead of XML give us any benefits there truly?

Re:Noob chiming in

[tepples]

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

[tepples]

Change "XML will still compress smaller than JSON" to "XML will still compress slightly larger than JSON".

And next week expect a YAML feed!

[Anonymous Coward]

But seriously, it sucks how many companies are pushing different formats for config files. Currently we're switching to/from Java property files, XML, JSON, and YAML and most any combination in between for different projects. It's amazing how, for example, the Google Dart people claim that JSON is too hard for programmers to learn so they moved their equivalent of a pom.xml file to YAML. It's insulting.

Podcasts would be the adoption moment I think.

[thewolfkin]

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

[Parker Lewis]

RSS is dead and replaced by Twitter. Of course, I use RSS, but RSS is too nerd for the average user.

Re:RSS is dead and replaced by...

[Anonymous Coward]

I thought there was no sign of RSS support visible on the surface in Firefox, so I checked. Amazingly it's there in the bookmarks menu, in the form of "Subscribe to this page...", but there's no icon next to the menu item.
In the sandwich/sewer grill/pancakes menu (or in toolbar if the bookmarks icon in there) the bookmarks menu doesn't offer the "Subscribe to this page..." feature.

I wonder why play UI mind games like that. It's stupid. But the RSS feature is still there (live bookmark with slashdot stuff works).
I agree only nerds know about it.

Re: RSS was too open

[thewolfkin]

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.

Not at all true

[SuperKendall]

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 community uses JSON rather heavily also (mostly because of REST calls but also for other purposes)...

Re:Not at all true

[Anonymous Coward]

> Are you not aware that the entire industry has moved to JSON for client to server transmission?

How the fuck do you VALIDATE that fucking stream of nonsense though? At least XML you can demand a fucking schema. JSON is just like a goofy version of binary's little brother.

JSON = Array

[Anonymous Coward]

JSON, new? Haven't arrays been around since... forever? If 30 years ago somebody asked me how to make a collection, I'd show them an array. I expect XML authors all knew this, but they chose XML anyway. I wonder why.

In a society based only on acquisition of wealth..

[zifn4b]

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!

Only adding confusion

[mpol]

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

[OrangeTide]

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

[WaffleMonster]

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.

Re:ASN.1 feeds announced as alternative to RSS

[Anonymous Coward]

The fields need to be fixed length and 6-bit BCD encoded so they can be processed by an IBM 704. Just in case someone is still using it production. Having upper and lower case letters is a luxury that not everyone can afford.

ORLY?

[Artem S. Tashkinov]

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.

Re:ORLY?

[OrangeTide]

XML is no longer popular because most web devs are unable to read a spec longer than a few pages. Outside of web development XML is still very widely used.

Yawn.

[Anonymous Coward]

Another solution to a problem we don't have. Yay.

Re:ISIS?

[jaklode]

ISIT

date_published is optional? Noooo...

[dhasenan]

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.

Duplicate Entries

[Damian Hole]

such as eliminating duplicate entries

I don't think even the editors could blame RSS for the dupes.

Re: RSS was too open

[Anonymous Coward]

I've been using Inoreader for the past year and it feels like the second coming of Google Reader. It even better, I'd say. I hardly even use reddit anymore.

XML Validation is really just design doc

[SuperKendall]

How the fuck do you VALIDATE that fucking stream of nonsense though?

Validation is highly overrated, I did a LOT of XML work back the day and validation was NEVER used in live systems.

In the end what validation was actually used for was simply a reference document describing what the XML would hold. But you can easily produce the same kind of document for any JSON structure, so that you developers know what to expect in the payload.

Once you have it all working, why do you need validation for a running system? What is the difference between a validation error and a parser error somewhere in the middle unwinding JSON in the way you are expecting?