27 ms·

JSON Feed

486 points by fold 9y ago

mindcrime 9y ago
Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.
- metheus 9y ago
 We don't prefer JSON to XML for any reason other than that XML is terrible by comparison.
 - bdr 9y ago
 That's not a reason.
 - dangerlibrary 9y ago
 It's funny to me that at the same time people are flocking to languages with strong, flexible type systems (often with compile-time checks), we are fleeing from a strongly typed data interchange format in favor of a dynamic bag of objects and arrays.
 - pg_is_a_butt 9y ago
 it's funny to me that you think those are "people"
 - algesten 9y ago
 I think that's because even if the data interchange format is strongly typed, as a consumer you often still must expect _anything_. I've yet to work on a project that handles XML where we have a XSD prevalidation step that makes the reading of some deeply nested XML tag feel safe. Unless we count XML <-> data object binding back in the java days. Not sure that felt any better...
 - eropple 9y ago
 On the flip side, I've only ever not had an XSD when I was building something myself and actively didn't care. The truth, I tend to suspect, lies somewhere in between. =)
- armandososa 9y ago
 It is very likely than I am an idiot, but I've always found parsing XML too hard, specially compared to JSON which is almost too easy.
 - mstade 9y ago
 If there was an `XML.parse` just like there's `JSON.parse`, I doubt you'd say the same. As it stands, the added complexity in JS-land is to import a library that provides this functionality for you. Fortunately there are many, but I agree a built-in would be nice. It's a bit of a shame that E4X never landed in JS.
 - moduspol 9y ago
 It's more than JUST library support. It's also that JSON deserializes into common native data types naturally (dictionary, list, string, number, null). You can deserialize XML into the same data types, but it's not anywhere near as clean because of how extensible XML is. That's a big part of what's made JSON successful.
 - dangerlibrary 9y ago
 This is really only true in dynamically typed languages. From personal experience: parsing json in Java or Go without just treating everything as a bag of Object or an interface{} requires a ton of menial boilerplate work. Super nice in python/ruby/javascript, though.
 moduspol 9y ago
 Sure--it's kind of a pain in Swift, too. Wouldn't it just be worse with XML, though? I get that people don't realistically parse it themselves and libraries are smart enough to use schemas to deserialize, but there's nothing inherent about JSON that makes it unable to conform to a schema or be parsable by libraries into native strongly-typed objects the same way.
 9y ago
- chc 9y ago
 You're basically saying that this isn't technically better, just more socially acceptable right now. I think you're right, but it seems to me that Atom's problem is primarily a social one. So even if this doesn't carry any technical advantages, a format with a strong social "in" is precisely what we need to make feeds a thing again.
- matthewaveryusa 9y ago
 Once you've peeked at the complexity of some of the xml parsers (like xerces, oh god xerces) undoubtedly you'll want to avoid it like the plague. xml can get crazy-bananas very quickly. I fundamentally don't understand xml (just like I don't understand asn1) for anything beyond historical purposes.
 - aloisdg 9y ago
 The Atom spec is really easy to grasp. Your platform may even include a way to deal with it ([.NET](https://msdn.microsoft.com/en-us/library/system.servicemodel.syndication.syndicationfeed(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.servicemodel... for example)
 - mindcrime 9y ago
 There are definitely complexities in the XML ecosystem, like XLink, schemas, namespaces, etc. But in practice, not every application needs all that stuff, and when using the "common" parts of XML, I don't find it difficult to understand or work with. But that's just me.
- djur 9y ago
 XML parsers have a pretty bad track record for security vulnerabilities. If I was writing code to distribute that was going to be parsing arbitrary data from third parties (which is the RSS/Atom use case), I would be more comfortable trusting the average JSON parser than the average XML parser. Otherwise, I agree with the "if it ain't broke" principle. There's also cases where so much ad hoc complexity is built on top of JSON that you end up with the same problems XML has, except with less battle-tested implementations.
 - tetrep 9y ago
 As terrible as XML parsers can be, they've never been as bad as "XMLdoc = eval(XMLString)". I'd be more likely to trust a JSON parser not written in JavaScript than an arbitrary XML parser, but that's only because of the XML specification itself, which includes such features as including arbitrary content as specified by URLs (including local (to the parser) files!). Great ideas when you can trust your XML document, not so great otherwise.
 - philsnow 9y ago
 modern browsers don't internally call eval(). See e.g. the definition of JSON.parse in v8: https://chromium.googlesource.com/v8/v8/+/4.3.65/src/json.js?autodive=0%2F%2F https://chromium.googlesource.com/v8/v8/+/4.3.65/src/json.js...
 - vsl 9y ago
 And modern XML parsers aren't full of vulnerabilities anymore. You're missing the point.
- pfranz 9y ago
 Part of me is with you. But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. I think with something like feeds there's the possible benefit of becoming a 'hello world' for frameworks. Many frameworks have you write a simple blogging engine or twitter copycat. I don't think I've ever seen that for a feed reader/publisher. People have said that Twitter clients were an interesting playground for new UI concepts and paradigms because the basics were so simple (back when their API keys were less restrictive). Maybe this could be that?
 - deleted 9y ago
 [deleted]
 - mindcrime 9y ago
 But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML - including Atom - in years. But I admit that other platforms might not have the same degree of support.
 - pfranz 9y ago
 Most of my experience is from Python. Each time I use it I have to look at the docs for etree (a library that ships with Python). We would hit performance and feature support issues with etree and tried lxml but had binary compatibility issues between our environments. The Hitchhiker's Guide to Python[1] (a popular reference for Python) recommends untangle[2] and xmltodict[3], neither of which I've used. I feel like in other languages I've used had similar brittleness when dealing with xml. I might be biased because working with xml in an editor it's difficult to validate visually or grok in general when used in practice. [1] http://python-guide-pt-br.readthedocs.io/en/latest/scenarios/xml/ http://python-guide-pt-br.readthedocs.io/en/latest/scenarios... [2] https://untangle.readthedocs.io/en/latest/ https://untangle.readthedocs.io/en/latest/ [3] https://github.com/martinblech/xmltodict https://github.com/martinblech/xmltodict
- oefrha 9y ago
 Yep, we don't really need another syndication format that no reader is going to support or support well for years. All I see missing in RFC 4287 is the lack of a per-entry cover image/thumbnail, which you can solve with an extension (which no one supports, and that's kind of the point) anyway.
- oxguy3 9y ago
 To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq (https://stedolan.github.io/jq/ https://stedolan.github.io/jq/) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.
 - sillysaurus3 9y ago
 Surely there's an xml->json converter somewhere.
 - duskwuff 9y ago
 It's kind of tough to convert XML directly to other formats (including, but not limited to, JSON), because there are a lot of XML features that don't map cleanly onto JSON, such as: • Text nodes (especially whitespace text nodes) • Comments • Attributes vs. child nodes • Ordering of child nodes
 - eponeponepon 9y ago
 As it happens, XSLT 3.0 and XPath 3.0 both have well documented and stable features for doing exactly this. Roundtripping XML to JSON and back is a solved problem - check it out some time; it may surprise you.
 ajanuary 9y ago
 Are you talking about json-to-xml and xml-to-json? From the XSLT spec [0]: "Converts an XML tree, whose format corresponds to the XML representation of JSON defined in this specification, into a string conforming to the JSON grammar" It can't take an arbitrary XML document and turn it into JSON, it can only take XML documents that conform to a specific format. You can safely round-trip from JSON to XML and back to JSON. That's trivial because JSONs feature set is a subset of XMLs. What you can't safely do is round-trip from arbitrary XML to JSON and back to XML. That's because, as the parent said, there are features in XML that don't exist in JSON. That means you are forced to find a way to encode it using the features you do have, but then you can't tell your encoding apart from valid values. [0] https://www.w3.org/TR/xslt-30/#func-xml-to-json https://www.w3.org/TR/xslt-30/#func-xml-to-json
- weberc2 9y ago
 Yikes, you didn't even make it to the second sentence. > JSON is simpler to read and write, and it’s less prone to bugs.
 - jwilk 9y ago
 From the HN guidelines: Please don't insinuate that someone hasn't read an article.
 - weberc2 9y ago
 My mistake for phrasing my point in a manner that violates HN guidelines. I tried to edit, but I missed the window. At any rate, my point stands.
 - mindcrime 9y ago
 JSON is simpler to read and write, and it’s less prone to bugs. I don't actually find either of those things to be true.
 - jack9 9y ago
 I simply think you're lying to yourself. It's both literally and theoretically simpler to write and digest let's start with the simplest case, {}. Prone to bugs is a matter of debate, depending on a number of factors.
 - weberc2 9y ago
 That's a fine opinion to have, but that doesn't mean that people (the authors or devs generally) use JSON out of vanity. As an aside, you're the first person I've heard suggest people put their identity in serialization format, which gave me a good laugh.
- wcummings 9y ago
 No, we don't. This doesn't do anything except break compatibility.
- hyperpallium 9y ago
 In practice, json is much easier to work with on the command line because of jq.
- robgibbons 9y ago
 JSON, given the same schema, will always be more efficient byte-for-byte than XML. In addition, JSON as a format is native to JavaScript, which itself is ubiquitous. That's not even mentioning raw readability/writability. Basically, XML is to JSON as SOAP is to REST. It had it's day, though it's obviously still useful, but we have better tools now. Frankly, I'm surprised we haven't seen a proposal like this sooner.
 - stephenr 9y ago
 > XML is to JSON as SOAP is to REST That's true. Both XML and SOAP are well defined, and well structured. JSON and REST are both marginally defined, and thus we see constant incompatible/incomplete implementations, or weird hacks to overcome the shortcomings. > we have better tools now I think "the cool kids are cargo-culting something newer now" is probably more accurate.
 - icebraining 9y ago
 Nitpick: REST is very well defined. It's not just a protocol, like some people insist. Other than that, fully in agreement.
 - stephenr 9y ago
 Rest is effectively a concept, and its up to developers to follow the rules it sets. You can't take your codebase, add some glue code to a REST module, and know that it will be usable by any other REST consumer/client, because no one follows the guidelines exactly the same way.
- liuyanghejerry 9y ago
 Part of me is also with you - JSON is indeed smaller than XML , but we do have gzip almost everywhere around the web, and with gzip, they don't have that much difference on space. Also, if people really care about this, why don't they use binary format, such as something like protobuf? And the other part of me is not with you - manipulating XML is not as easy as JSON in most of my development time, and sometimes I even need to write something by my bare hands, which JSON is much more handy. Tons of other formats are more human-friendly than JSON, for example TOML, but they don't have the status JSON has. So I guess JSON is kinda choice under the current state of "web development times".
- revelation 9y ago
 Yeah this is great, now instead of properly machine-readable and verifiable XSD files we have pseudo-RFC text on some shitty GitHub page.
fergbrain 9y ago
https://xkcd.com/927/ https://xkcd.com/927/
- deleted 9y ago
  [deleted]
pimlottc 9y ago
> JSON is simpler to read and write, and it’s less prone to bugs. Less prone to bugs? How's that?
- skybrian 9y ago
  RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.
  - CharlesW 9y ago
    > RSS is sometimes ambiguous and there's a lot of variation. I've written a reasonably-popular podcast feed validator, and I don't understand either of these criticisms. Mind elaborating?
    - bastawhiz 9y ago
      > I've written a reasonably-popular podcast feed validator Mind sharing?
      - dsp1234 9y ago
        https://podba.se/validate/ https://podba.se/validate/
        bastawhiz 9y ago
        Nice, very cool! Definitely an improvement on the trash legacy validators out there.
      - deleted 9y ago
        [deleted]
    - skybrian 9y ago
      Since you've done it recently, I'm sure you know more than I do; I suspect my knowledge of it is obsolete.
voidfiles 9y ago
This seems like a great idea. If it can help even one developer it's worth it.
- CharlesW 9y ago
  How would it help even one developer? Or asked another way, what problem does this solve for you?
  - voidfiles 9y ago
    So, my personal blog doesn't get a ton of traffic, but the one article that gets the most traffic is an article about how to monkeypatch feedparser to not strip about embedded videos. While not hard evidence, I think it's indicative of the kind of experience a developer has when they choose to engage with syndication.
einrealist 9y ago
If you create a new JSON-based document format, please consider to use JSON-LD (aside raw JSON data) so we can make a true world of interconnected data through semantic formats. At least, so I can generate code and automatically validate format compatibility from a well-defined schema. Thank you! EDIT: Because I get downvoted despite stating my opinion on the topic, I adjusted the statement.
- strictnein 9y ago
  No, please don't.
  - dabernathy89 9y ago
    Well now I don't know what to think.
  - einrealist 9y ago
    Why not?
jerf 9y ago
I would suggest specifying titles as html, not plain text. I've seen too many things titled "I love science!" over the years to believe in the idea that titles are plain text. Also, despite the fact this is technically not the responsibility of the spec itself, I would strongly suggest some words on the implications of the fact that the HTML fields are indeed HTML and the wisdom of passing them through some sort of HTML filter before displaying them. In fact that's also part of why I suggest going ahead and letting titles contain HTML. All HTML is going to need to be filtered anyhow, and it's OK for clients to filter titles to a smaller valid tag list, or even filter out all tags. Suggesting (but not mandating) a very basic list of tags for that field might be a good compromise.
- ergothus 9y ago
 Allowing HTML means the other side will have to validate that HTML (to avoid XSS). Using text means you can stick in the DOM using innerText() and be much more confident that you aren't injected XSS. I agree that I see HTML in RSS titles, but I rather have the occasional garbled title that the author can fix by striping out HTML before the RSS than ensuring that every RSS reader isn't opening up new security holes.
 - jerf 9y ago
 There is no way to avoid having to handle HTML safely. There's no point in trying to limit your exposure to that problem when the entire point of this standard is to ship around arbitrary HTML for interfaces to display. Once you've solved the hard problem of displaying the body safely, displaying the title is trivial. Making the title pure text does nothing useful. JSONFeed display mechanisms that are going to get this wrong are going to do things like leave injections in the date fields anyhow.
- ianburrell 9y ago
 Following the separation of content_text and content_html attributes, it would make sense to have title_html and title_text attributes.
nilved 9y ago
Good lord, Web people, stop it. You are embarrassing yourselves. We already have standards and you need to stop recreating everything in JavaScript.
- frou_dh 9y ago
  Brent Simmons is hardly some webdev kid barging it. He was the original developer of NetNewsWire, a very popular/influential feed reader application which is now 15(!) years old.
  - smilbandit 9y ago
    thanks, knew I recognized the name
pswenson 9y ago
i'm surprised no one has started a snake vs camel case debate here! https://jsonfeed.org/version/1 https://jsonfeed.org/version/1
mstade 9y ago
> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please don't try to overload media types like this. Atom isn't served as `application/xml` precisely because it isn't XML; it's served as `application/atom+xml`. For a media type that is JSON-like but isn't JSON, you may wish to look at `application/hal+json`; incidentally there's also `application/hal+xml` for the XML variant. Or as someone else rightly suggested, consider just using JSON-LD.
- anshou- 9y ago
  It's worth pointing out that any valid JSON value is a valid JSON document. There is no requirement or guarantee that an array or an object are the top-level value in a JSON document. "I am a valid JSON document. So is the Number below, and in fact every line below this line." 4 null
  - niftich 9y ago
    true
  - mstade 9y ago
    You're right, thanks for the correction! Also kind of reinforces my point I feel. That any JSON document is just that, a JSON document; it doesn't carry more semantics just because you say so. My JSON parser will still just see simple JSON values, no matter how much I tell it that a certain key should really be a URL, not just a string.
    - tghw 9y ago
      True, but that's also true of any XML, RSS, Atom, HTML, etc. Websites abuse HTML all the time, and there's nothing saying that just because something is transferred with application/atom+xml that it will be valid or follow the spec. It's more of a social agreement. If you get a JSON object from a place you expect a JSON Feed and it has a title and items, then it'll probably work, even if it omits other things.
CharlesW 9y ago
Dave Winer (the creator of RSS) played with this a bit in 2012. It turns out that exact format of feeds doesn't matter nearly as much as there being a more-or-less universal one. http://scripting.com/stories/2012/09/10/rssInJsonForReal.html http://scripting.com/stories/2012/09/10/rssInJsonForReal.htm...
- AceJohnny2 9y ago
  I'm sure there's... oh of course: https://xkcd.com/927/ https://xkcd.com/927/ (and I realize this doesn't exactly map, as JSON Feed isn't even trying to cover all the usecases of Atom or RSS, just switching the container format)
gumby 9y ago
A good announcement explains what problem it is intending to solve.
ozten 9y ago
XML is aweful, but it does have CDATA, which lets you embed blog posts directly and it's easy to debug. String encoded blog posts are going to be painful once people start using the `content_html` part of the spec.
- __david__ 9y ago
  Naw, JSON has reasonable quoting in the strings. It's maybe painful to read the raw json, but it encodes just fine.
gedrap 9y ago
But does it solve any actual problems other than 'XML is not cool', problems big enough to deserve a new format? It's true that JSON is easier to deal with than XML. But that's relative, there are plenty of decent tools around RSS. From readers, to libraries in the most common programming languages, and extensions in the most common content management systems. JSON is slightly easier to read for human (although that's subjective), but then how often do you need to read the RSS feed manually, unless you are the one who is writing those libraries, etc. But that's a tiny share of all people using RSS. >>> It reflects the lessons learned from our years of work reading and publishing feeds. Sounds like the author(s) has extensive experience in this field and knows things better than some random person on the internet (me). But the homepage of the project doesn't convey those learned lessons.
- tannhaeuser 9y ago
  Yes JSON is much easier to parse than XML, and is preferred when it fits such as for most Web API requests and responses. However, SGML and XML were invented as structured markup languages for authoring of rich text documents by humans, for which JSON is unsuited and sucks just as much as XML sucks for APIs. Edit: though XML has its place in many b2b and business-to-government data exchanges (financial and tax reporting, medical data exchange, and many others) where a robust and capable up-front data format specification for complex data is required
jawns 9y ago
> It's at version 1, which may be the only version ever needed. Wow. Now that's confidence. Have you ever read the first version of a spec and thought, "That's just perfect. Any additional changes would just be a disappointment compared with the original"?
- smacktoward 9y ago
  "Now it belongs to the ages!"
- Johnny_Brahms 9y ago
  MIDI 1.0 is maybe not perfect, but it is still unchanged since 1983. People have tried to replace it for 2 decades, but failed to provide any enhancements worth a switch. But MIDI doesn't really fit that description since it builds on 2 years of work by Roland. My best bet though.
- efsavage 9y ago
  Unsurprising as this is clearly an ego play, given that the first thing they want you to know is their names.
- vanderZwan 9y ago
  In all fairness, they're taking a more or less solved problem (feeds), so they don't really have to figure things out there, and they're porting this established solution to a very well-established technology (JSON), so also don't really have to figure stuff out in that sense either. As far as scenarios where it's feasible to get the answer right the first time go, this is a reasonably realistic one. EDIT: Also, if you scroll to the bottom of the page you can see they have let a whole bunch of people look at the spec before releasing it, so there has been at least some peer review.
0x006A 9y ago
why is it size_in_bytes and duration_in_seconds as opposed to content_text and content_html It should just be size and duration or size_bytes size_seconds (but adding units only makes sense if you could use other units). adding _in to the mix is strange.
smilbandit 9y ago
I'd like to see a language available at the item level. You can derive the language from the http headers but if you're dealing with linkblogs it would be nice at the item level to help with filtering. I think that images and urls would do well as order lists rather than as individual values. at the top level you have 3 urls and an array for hubs. with type and url you could have an array for hubs and the urls. same could be done for images at the top level and both again at the item level.
niftich 9y ago
It's unfortunate that XML has fallen so out of favor that well-made, strongly-schemad formats specified in XML, like Atom, are suffering in turn -- although reasons for feeds' demise go well beyond its forms-on-the-wire. This trend frustrates me, but it's undeniable that a lot of web data interchange happens with JSON-based formats nowadays, and the benefits of network effects, familiarity, and tooling support make JSONification worth exploring. But even more frustrating is when a format comes out that's close to being a faithful translation of an established format, but makes small, incompatible changes that push the burden of faithful translation onto content authors, or the makers of third-party libraries. I honestly don't intend to offer harsh targeted critique against the authors -- I assume good faith; more just voicing exasperation. There have been similar attempts over the years -- one from Dave Winer, the creator of RSS 0.92 and RSS 2.0, called RSS.js [1], which stoked some interest at first [2]; others by devs working in isolation without seeming access to a search engine and completely unaware of prior art; some who are just trying something unrelated and accidentally produce something usable [3]; finally, this question pops up from time to time on forums where people with an interest in this subject tend to congregate [4]. Meanwhile, real standards-bodies are off doing stuff that reframes the problem entirely [5] -- which seems out-of-touch at first, but I'd argue provides a better approach than similar-but-not-entirely-compatible riff on something really old. And as a meta, "people who use JSON-based formats", as a loose aggregate, have a serious and latent disagreement about whether data should have a schema or even a formal spec. In the beginning when people first started using JSON instead of XML, it was done in a schemaless way, and making sense of it was strictly best-effort on part of the receiving party. Then a movement appeared to bring schemas to JSON, which went against the original reason for using JSON in the first place, and now we're stuck with the two camps playing in the same sandbox whose views, use-cases, and goals are contradictory. This appears to be a "classic" loose JSON format, not a strictly-schemad JSON format, not even bothering to declare its own mediatype. This invites criticism from the other camp, yet the authors are clearly not playing in that arena. What's the long-term solution here? [1] http://scripting.com/stories/2012/09/10/rssInJsonForReal.html http://scripting.com/stories/2012/09/10/rssInJsonForReal.htm... [2] https://core.trac.wordpress.org/ticket/25639 https://core.trac.wordpress.org/ticket/25639 [3] http://www.giantflyingsaucer.com/blog/?p=3521 http://www.giantflyingsaucer.com/blog/?p=3521 [4] https://groups.google.com/forum/#!topic/restful-json/gkaZl3AtiPk https://groups.google.com/forum/#!topic/restful-json/gkaZl3A... [5] https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/
zeveb 9y ago
If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html "Hello, world!") (url https://example.org/initial-post)))) This looks much nicer IMHO than their first example: { "version": "https://jsonfeed.org/version/1", "title": "My Example Feed", "home_page_url": "https://example.org/", "feed_url": "https://example.org/feed.json", "items": [ { "id": "2", "content_text": "This is a second item.", "url": "https://example.org/second-item" }, { "id": "1", "content_html": "Hello, world!", "url": "https://example.org/initial-post" } ] }
- foxhill 9y ago
 beauty is in the eye of the beholder - i personally prefer the JSON.
- JoelSanchez 9y ago
 There's EDN, which is to Clojure what JSON is to JS: a format close to the language's way of representing data. https://github.com/edn-format/edn https://github.com/edn-format/edn Example: https://github.com/milikicn/activity-stream-example/blob/4dbc15364dbf636ecf8500b2c2ae4a16bbdd73f9/resources/migrations/activity_streams/seed/data.edn https://github.com/milikicn/activity-stream-example/blob/4db... Not S-expression-based, though.
- krapp 9y ago
 It looks nicer if you happen to like s-expressions. But to me, it's just replacing one flavor of clutter for another. The best reason not to prefer s-expressions to JSON, though, would be simply that one is already natively supported in browsers and the other would need a parser written in a language that already parses JSON.
- 9y ago
cocktailpeanuts 9y ago
Doesn't Wordpress already have something like this? http://v2.wp-api.org/ http://v2.wp-api.org/ I don't understand why suddenly people treat this like something that uniquely solves a problem. Maybe I'm missing something?
- yoz-y 9y ago
  This format is more akin to RSS than to a programmatic rest API. The main goal is to be able to avoid the pitfalls of parsing Atom and RSS feeds. Both Brent Simmons and Manton Reece are quite active in making decentralized alternatives for self publishing for which RSS is the current backbone.
  - donohoe 9y ago
    Parsing RSS and Atom feeds is a solved problem, no?
    - yoz-y 9y ago
      JSON Feed is a new solution for the problem already solved by RSS or Atom. It makes it easier to develop new publishers and consumers. It also tackles the main problems with these two formats, e.g.: no realtime subscriptions, mandatory titles which are a pain for microblogs, potential security problems with XML and so on. Like somebody somewhere has written: If no one had ever reinvented the real wheel - our cars would be rolling around on big wooden logs
russellbeattie 9y ago
For anyone who's tried to write a real-world RSS feed reader, this format does little to solve the big problems the newsfeeds have: * Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely. * Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do a delta on the entire feed if there is new or updated content. Also, if you missed 10 updates, and the feed only contains the last 5 items, then you lose information. This is the nature of a document-centric feed meant to be served as a static file. But it's 2017 now, and it's incredibly rare that a feed isn't created dynamically. A new feed spec should incorporate that reality. * Complete understanding of modern content types besides blog posts? Miss. The last time I went through a huge list of feeds for testing, I found there were over 50 commonly used namespaces and over 300 unique fields used. RSS is used for everything from search results to Twitter posts to Podcasts... It's hard to describe all the different forms of data it can be contain. The reason for this is because the original RSS spec was so minimal (there's like 5 required fields) so everything else has just been bolted on. JSONFeed makes this same mistake. * An understanding that separate but equal isn't equal. Miss. The thing that http://activitystrea.ms http://activitystrea.ms got right was the realization that copying content into a feed just ends up diluting the original content formatting, so instead it just contains metadata and points to the original source URL rather than trying to contain it. If JSONFeed wanted to really create a successor to RSS, it would spec out how to send along formatting information along with the data. It's not impossible - look at what Google did with AMP: They specified a subset of formatting options so that each article can still contain a unique design, but limited the options to increase efficiency and limit bugs/chaos. This stuff is just off the top of my head. If you're going to make a new feed format in 2017, I'm sorry but copying what came before it and throwing it into JSON just isn't enough.
- hboon 9y ago
  FWIW, This is by Manton Reece and Brent Simmons. And Simmons is known (among other things) as the creator of NetNewsWire which has been around for more than 15 years. He does know a bit about Atom and RSS feeds. https://en.wikipedia.org/wiki/NetNewsWire https://en.wikipedia.org/wiki/NetNewsWire
eric_the_read 9y ago
A few thoughts on the spec itself: * In all cases (feed and items), the author field should be an array to allow for feeds with more than one author (for instance, a podcast might want to use this field for each of its hosts, or possibly even guests). * external_url should probably be an array, too, in case you want to refer to multiple external resources about a specific topic, or in the case of a linkblog or podcast that discusses multiple topics, it could link to each subtopic. * It might be nice if an item's ID could be enforced to a specific format, even if perhaps only within a single feed. Otherwise it's hard to know how to interpret posts with IDs like "potato", 1, null, "http://cheez.burger/arghlebarghle" http://cheez.burger/arghlebarghle"
- derefr 9y ago
  > a podcast might want to use this field for each of its hosts, or possibly even guests I'm going to pretend this is about music artists in a music library, but the logic is exactly the same for podcast hosts: You tend to want fields like this to be singular, so that the field can be used in collation (i.e. "sort by artist.") If you have multiple artists for a track, usually one can be designated the "primary" artist—the one that people best know, and would expect to find the track listed under when looking through their library. Usually, then, the rest get tacked on in the field in a freeform, maybe comma-and-space delimited fashion. The field isn't a strict strongly-typed references(Person) field, after all; it's just freeform text describing the authorship. But as for hosts vs. guests, that's a whole can of worms. Look at the ID3 standard. Even though music library-management programs usually just surface an "Artist" field, you've actually got all of these separate (optional) fields embedded in each track: • TCOM: Composer • TEXT: Lyricist/Text writer • TPE1: Lead performer(s)/Soloist(s) • WOAR: Official artist/performer webpage • TPE2: Band/orchestra/accompaniment • TPE3: Conductor/performer refinement • TPE4: Interpreted, remixed, or otherwise modified by • TENC: Encoded by • WOAS: Official audio source webpage • TCOP: Copyright message • WPUB: Publishers official webpage • TRSN: Internet radio station name • TRSO: Internet radio station owner • WORS: Official internet radio station homepage That gives you separate credits for pretty much the entire composition, production and distribution flow, which usually means that each field only needs one entry. Would be great if people used them, wouldn't it? Maybe the semi-standard "A feat. B (C remix)" microformat could be parsed into "[TPE2] feat. [TPE1] ([TPE4])"...
ehosca 9y ago
stopped reading after "JSON is simpler to read and write, and it’s less prone to bugs." ....
ttepasse 9y ago
Shortly after RSS 0.9 came out RSS 1.0 reformulated the RSS vocabulary in RDF terms. Of course the modern (sane) successor to RDF/XML is JSON-LD. So I'm hoping for JSON-LD Feed 1.1 and a new war of format battles. Maybe we can even get Mark Pilgrim out of hiding!
- toyg 9y ago
  Someone should open a social network for feed-wars veterans. More seriously, it's sad so to see that almost 20 years later, the dream of a decentralised and bidirectional web is in even worse shape than it was back then.
  - bullen 9y ago
    Yes, extend this to JSON pingback and bring back the decentralized social web.
donohoe 9y ago
I have grave concerns that this publishing format is delivered to us by two people that, as far as I can see, have limited to zero publishing background. That said, they're being responsive to questions in Issues, so I remain optimistic.
- acdha 9y ago
  Learning about the history of RSS should alleviate your concerns. Brent Simmons has been working in the space for 15 years, writing one of the more popular clients and working at a company which provided sync and syndication services: https://en.wikipedia.org/wiki/NetNewsWire#History https://en.wikipedia.org/wiki/NetNewsWire#History
Communitivity 9y ago
It is worth pointing out that there is a relevant W3C Recommendation "JSON Activity Streams", https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/ . I'm not saying JSON Feed is worse, or better. I am saying that I think JSON Feeds adoption requires a detailed comparison between JSONFeed and JSON Activity Streams 2.0.
- smilbandit 9y ago
  Thanks +1, didn't know that.
pedalpete 9y ago
"JSON has become the developers’ choice for APIs", I'm curious about how people feel about this statement from a creation vs consumption perspective. I'm currently creating an API where I'm asking devs to post JSON rather than a bunch of separate parameters, but I haven't seen this done in other APIs (if you have, can you point me to a few examples?). I'm curious what others thoughts are on this. It seems that with GraphQl, we're maybe starting to move in this direction.
systematical 9y ago
Who uses feeds? Who uses XML?
gwu78 9y ago
Is this a "JSON Feed" from NYTimes? Example below filters out all URLs for a specific section of the paper. test $# = 1 ||exec echo usage: $0 section curl -o 1.json https://static01.nyt.com/services/json/sectionfronts/$1/index.jsonp exec sed '/\"guid\" :/!d;s/\",//;s/.*\"//' 1.json I guess SpiderBytes could be used for older articles? Personally, I think a protocol like netstrings/bencode is better than JSON because it better respects the memory resources of the user's computer. Every proposed protocol will have tradeoffs. To me, RAM is sacred. I can "parse" netstrings in one pass but I have been unable to do this with a state machine for JSON. I have to arbitrarily limit the number of states or risk a crash. As easy as it is to exhaust a user's available RAM with Javascript so too can this be done with JSON. Indeed they go well together.
bullen 9y ago
I miss the distributed social pingback days! Implemented: http://sprout.rupy.se/feed?json http://sprout.rupy.se/feed?json
thibaudgg 9y ago
Just added JSON feed support to https://applefocus.com https://applefocus.com (https://applefocus.com/feed.json https://applefocus.com/feed.json), JSON FTW!

486 points by fold 9y ago

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

metheus 9y ago
We don't prefer JSON to XML for any reason other than that XML is terrible by comparison.
- bdr 9y ago
 That's not a reason.
- dangerlibrary 9y ago
 It's funny to me that at the same time people are flocking to languages with strong, flexible type systems (often with compile-time checks), we are fleeing from a strongly typed data interchange format in favor of a dynamic bag of objects and arrays.
 - pg_is_a_butt 9y ago
 it's funny to me that you think those are "people"
 - algesten 9y ago
 I think that's because even if the data interchange format is strongly typed, as a consumer you often still must expect _anything_. I've yet to work on a project that handles XML where we have a XSD prevalidation step that makes the reading of some deeply nested XML tag feel safe. Unless we count XML <-> data object binding back in the java days. Not sure that felt any better...
 - eropple 9y ago
 On the flip side, I've only ever not had an XSD when I was building something myself and actively didn't care. The truth, I tend to suspect, lies somewhere in between. =)
armandososa 9y ago
It is very likely than I am an idiot, but I've always found parsing XML too hard, specially compared to JSON which is almost too easy.
- mstade 9y ago
  If there was an `XML.parse` just like there's `JSON.parse`, I doubt you'd say the same. As it stands, the added complexity in JS-land is to import a library that provides this functionality for you. Fortunately there are many, but I agree a built-in would be nice. It's a bit of a shame that E4X never landed in JS.
  - moduspol 9y ago
    It's more than JUST library support. It's also that JSON deserializes into common native data types naturally (dictionary, list, string, number, null). You can deserialize XML into the same data types, but it's not anywhere near as clean because of how extensible XML is. That's a big part of what's made JSON successful.
    - dangerlibrary 9y ago
      This is really only true in dynamically typed languages. From personal experience: parsing json in Java or Go without just treating everything as a bag of Object or an interface{} requires a ton of menial boilerplate work. Super nice in python/ruby/javascript, though.
      - moduspol 9y ago
        Sure--it's kind of a pain in Swift, too. Wouldn't it just be worse with XML, though? I get that people don't realistically parse it themselves and libraries are smart enough to use schemas to deserialize, but there's nothing inherent about JSON that makes it unable to conform to a schema or be parsable by libraries into native strongly-typed objects the same way.
        9y ago
chc 9y ago
You're basically saying that this isn't technically better, just more socially acceptable right now. I think you're right, but it seems to me that Atom's problem is primarily a social one. So even if this doesn't carry any technical advantages, a format with a strong social "in" is precisely what we need to make feeds a thing again.
matthewaveryusa 9y ago
Once you've peeked at the complexity of some of the xml parsers (like xerces, oh god xerces) undoubtedly you'll want to avoid it like the plague. xml can get crazy-bananas very quickly. I fundamentally don't understand xml (just like I don't understand asn1) for anything beyond historical purposes.
- aloisdg 9y ago
  The Atom spec is really easy to grasp. Your platform may even include a way to deal with it ([.NET](https://msdn.microsoft.com/en-us/library/system.servicemodel.syndication.syndicationfeed(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.servicemodel... for example)
- mindcrime 9y ago
  There are definitely complexities in the XML ecosystem, like XLink, schemas, namespaces, etc. But in practice, not every application needs all that stuff, and when using the "common" parts of XML, I don't find it difficult to understand or work with. But that's just me.
djur 9y ago
XML parsers have a pretty bad track record for security vulnerabilities. If I was writing code to distribute that was going to be parsing arbitrary data from third parties (which is the RSS/Atom use case), I would be more comfortable trusting the average JSON parser than the average XML parser. Otherwise, I agree with the "if it ain't broke" principle. There's also cases where so much ad hoc complexity is built on top of JSON that you end up with the same problems XML has, except with less battle-tested implementations.
- tetrep 9y ago
  As terrible as XML parsers can be, they've never been as bad as "XMLdoc = eval(XMLString)". I'd be more likely to trust a JSON parser not written in JavaScript than an arbitrary XML parser, but that's only because of the XML specification itself, which includes such features as including arbitrary content as specified by URLs (including local (to the parser) files!). Great ideas when you can trust your XML document, not so great otherwise.
  - philsnow 9y ago
    modern browsers don't internally call eval(). See e.g. the definition of JSON.parse in v8: https://chromium.googlesource.com/v8/v8/+/4.3.65/src/json.js?autodive=0%2F%2F https://chromium.googlesource.com/v8/v8/+/4.3.65/src/json.js...
    - vsl 9y ago
      And modern XML parsers aren't full of vulnerabilities anymore. You're missing the point.
pfranz 9y ago
Part of me is with you. But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. I think with something like feeds there's the possible benefit of becoming a 'hello world' for frameworks. Many frameworks have you write a simple blogging engine or twitter copycat. I don't think I've ever seen that for a feed reader/publisher. People have said that Twitter clients were an interesting playground for new UI concepts and paradigms because the basics were so simple (back when their API keys were less restrictive). Maybe this could be that?
- deleted 9y ago
  [deleted]
- mindcrime 9y ago
  But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML - including Atom - in years. But I admit that other platforms might not have the same degree of support.
  - pfranz 9y ago
    Most of my experience is from Python. Each time I use it I have to look at the docs for etree (a library that ships with Python). We would hit performance and feature support issues with etree and tried lxml but had binary compatibility issues between our environments. The Hitchhiker's Guide to Python[1] (a popular reference for Python) recommends untangle[2] and xmltodict[3], neither of which I've used. I feel like in other languages I've used had similar brittleness when dealing with xml. I might be biased because working with xml in an editor it's difficult to validate visually or grok in general when used in practice. [1] http://python-guide-pt-br.readthedocs.io/en/latest/scenarios/xml/ http://python-guide-pt-br.readthedocs.io/en/latest/scenarios... [2] https://untangle.readthedocs.io/en/latest/ https://untangle.readthedocs.io/en/latest/ [3] https://github.com/martinblech/xmltodict https://github.com/martinblech/xmltodict
oefrha 9y ago
Yep, we don't really need another syndication format that no reader is going to support or support well for years. All I see missing in RFC 4287 is the lack of a per-entry cover image/thumbnail, which you can solve with an extension (which no one supports, and that's kind of the point) anyway.
oxguy3 9y ago
To be honest, I'm really excited about the prospect of JSON based feeds. Right now, there's no easy way to work with Atom/RSS feeds on the command-line (that I know of anyway), which is something I often wish I could do. With a JSON feed, I can just throw the data at jq (https://stedolan.github.io/jq/ https://stedolan.github.io/jq/) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.
- sillysaurus3 9y ago
  Surely there's an xml->json converter somewhere.
  - duskwuff 9y ago
    It's kind of tough to convert XML directly to other formats (including, but not limited to, JSON), because there are a lot of XML features that don't map cleanly onto JSON, such as: • Text nodes (especially whitespace text nodes) • Comments • Attributes vs. child nodes • Ordering of child nodes
    - eponeponepon 9y ago
      As it happens, XSLT 3.0 and XPath 3.0 both have well documented and stable features for doing exactly this. Roundtripping XML to JSON and back is a solved problem - check it out some time; it may surprise you.
      - ajanuary 9y ago
        Are you talking about json-to-xml and xml-to-json? From the XSLT spec [0]: "Converts an XML tree, whose format corresponds to the XML representation of JSON defined in this specification, into a string conforming to the JSON grammar" It can't take an arbitrary XML document and turn it into JSON, it can only take XML documents that conform to a specific format. You can safely round-trip from JSON to XML and back to JSON. That's trivial because JSONs feature set is a subset of XMLs. What you can't safely do is round-trip from arbitrary XML to JSON and back to XML. That's because, as the parent said, there are features in XML that don't exist in JSON. That means you are forced to find a way to encode it using the features you do have, but then you can't tell your encoding apart from valid values. [0] https://www.w3.org/TR/xslt-30/#func-xml-to-json https://www.w3.org/TR/xslt-30/#func-xml-to-json
weberc2 9y ago
Yikes, you didn't even make it to the second sentence. > JSON is simpler to read and write, and it’s less prone to bugs.
- jwilk 9y ago
  From the HN guidelines: Please don't insinuate that someone hasn't read an article.
  - weberc2 9y ago
    My mistake for phrasing my point in a manner that violates HN guidelines. I tried to edit, but I missed the window. At any rate, my point stands.
- mindcrime 9y ago
  JSON is simpler to read and write, and it’s less prone to bugs. I don't actually find either of those things to be true.
  - jack9 9y ago
    I simply think you're lying to yourself. It's both literally and theoretically simpler to write and digest let's start with the simplest case, {}. Prone to bugs is a matter of debate, depending on a number of factors.
  - weberc2 9y ago
    That's a fine opinion to have, but that doesn't mean that people (the authors or devs generally) use JSON out of vanity. As an aside, you're the first person I've heard suggest people put their identity in serialization format, which gave me a good laugh.
wcummings 9y ago
No, we don't. This doesn't do anything except break compatibility.
hyperpallium 9y ago
In practice, json is much easier to work with on the command line because of jq.
robgibbons 9y ago
JSON, given the same schema, will always be more efficient byte-for-byte than XML. In addition, JSON as a format is native to JavaScript, which itself is ubiquitous. That's not even mentioning raw readability/writability. Basically, XML is to JSON as SOAP is to REST. It had it's day, though it's obviously still useful, but we have better tools now. Frankly, I'm surprised we haven't seen a proposal like this sooner.
- stephenr 9y ago
  > XML is to JSON as SOAP is to REST That's true. Both XML and SOAP are well defined, and well structured. JSON and REST are both marginally defined, and thus we see constant incompatible/incomplete implementations, or weird hacks to overcome the shortcomings. > we have better tools now I think "the cool kids are cargo-culting something newer now" is probably more accurate.
  - icebraining 9y ago
    Nitpick: REST is very well defined. It's not just a protocol, like some people insist. Other than that, fully in agreement.
    - stephenr 9y ago
      Rest is effectively a concept, and its up to developers to follow the rules it sets. You can't take your codebase, add some glue code to a REST module, and know that it will be usable by any other REST consumer/client, because no one follows the guidelines exactly the same way.
liuyanghejerry 9y ago
Part of me is also with you - JSON is indeed smaller than XML , but we do have gzip almost everywhere around the web, and with gzip, they don't have that much difference on space. Also, if people really care about this, why don't they use binary format, such as something like protobuf? And the other part of me is not with you - manipulating XML is not as easy as JSON in most of my development time, and sometimes I even need to write something by my bare hands, which JSON is much more handy. Tons of other formats are more human-friendly than JSON, for example TOML, but they don't have the status JSON has. So I guess JSON is kinda choice under the current state of "web development times".
revelation 9y ago
Yeah this is great, now instead of properly machine-readable and verifiable XSD files we have pseudo-RFC text on some shitty GitHub page.

fergbrain 9y ago

https://xkcd.com/927/ https://xkcd.com/927/

deleted 9y ago
[deleted]

pimlottc 9y ago

> JSON is simpler to read and write, and it’s less prone to bugs. Less prone to bugs? How's that?

skybrian 9y ago
RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.
- CharlesW 9y ago
  > RSS is sometimes ambiguous and there's a lot of variation. I've written a reasonably-popular podcast feed validator, and I don't understand either of these criticisms. Mind elaborating?
  - bastawhiz 9y ago
    > I've written a reasonably-popular podcast feed validator Mind sharing?
    - dsp1234 9y ago
      https://podba.se/validate/ https://podba.se/validate/
      - bastawhiz 9y ago
        Nice, very cool! Definitely an improvement on the trash legacy validators out there.
    - deleted 9y ago
      [deleted]
  - skybrian 9y ago
    Since you've done it recently, I'm sure you know more than I do; I suspect my knowledge of it is obsolete.

voidfiles 9y ago

This seems like a great idea. If it can help even one developer it's worth it.

CharlesW 9y ago
How would it help even one developer? Or asked another way, what problem does this solve for you?
- voidfiles 9y ago
  So, my personal blog doesn't get a ton of traffic, but the one article that gets the most traffic is an article about how to monkeypatch feedparser to not strip about embedded videos. While not hard evidence, I think it's indicative of the kind of experience a developer has when they choose to engage with syndication.

einrealist 9y ago

If you create a new JSON-based document format, please consider to use JSON-LD (aside raw JSON data) so we can make a true world of interconnected data through semantic formats. At least, so I can generate code and automatically validate format compatibility from a well-defined schema. Thank you! EDIT: Because I get downvoted despite stating my opinion on the topic, I adjusted the statement.

strictnein 9y ago
No, please don't.
- dabernathy89 9y ago
  Well now I don't know what to think.
- einrealist 9y ago
  Why not?

jerf 9y ago

I would suggest specifying titles as html, not plain text. I've seen too many things titled "I love science!" over the years to believe in the idea that titles are plain text. Also, despite the fact this is technically not the responsibility of the spec itself, I would strongly suggest some words on the implications of the fact that the HTML fields are indeed HTML and the wisdom of passing them through some sort of HTML filter before displaying them. In fact that's also part of why I suggest going ahead and letting titles contain HTML. All HTML is going to need to be filtered anyhow, and it's OK for clients to filter titles to a smaller valid tag list, or even filter out all tags. Suggesting (but not mandating) a very basic list of tags for that field might be a good compromise.

ergothus 9y ago
Allowing HTML means the other side will have to validate that HTML (to avoid XSS). Using text means you can stick in the DOM using innerText() and be much more confident that you aren't injected XSS. I agree that I see HTML in RSS titles, but I rather have the occasional garbled title that the author can fix by striping out HTML before the RSS than ensuring that every RSS reader isn't opening up new security holes.
- jerf 9y ago
  There is no way to avoid having to handle HTML safely. There's no point in trying to limit your exposure to that problem when the entire point of this standard is to ship around arbitrary HTML for interfaces to display. Once you've solved the hard problem of displaying the body safely, displaying the title is trivial. Making the title pure text does nothing useful. JSONFeed display mechanisms that are going to get this wrong are going to do things like leave injections in the date fields anyhow.
ianburrell 9y ago
Following the separation of content_text and content_html attributes, it would make sense to have title_html and title_text attributes.

nilved 9y ago

Good lord, Web people, stop it. You are embarrassing yourselves. We already have standards and you need to stop recreating everything in JavaScript.

frou_dh 9y ago
Brent Simmons is hardly some webdev kid barging it. He was the original developer of NetNewsWire, a very popular/influential feed reader application which is now 15(!) years old.
- smilbandit 9y ago
  thanks, knew I recognized the name

pswenson 9y ago

i'm surprised no one has started a snake vs camel case debate here! https://jsonfeed.org/version/1 https://jsonfeed.org/version/1

mstade 9y ago

> JSON Feed files must be served using the same MIME type — application/json — that’s used whenever JSON is served. So then it's JSON, and I'll treat it as any other JSON: a document that is either an object or an array, that can include other objects or arrays, as well as numbers and strings. Property names doesn't matter, nor do order of properties or array items, or whatever values are contained therein. Please don't try to overload media types like this. Atom isn't served as `application/xml` precisely because it isn't XML; it's served as `application/atom+xml`. For a media type that is JSON-like but isn't JSON, you may wish to look at `application/hal+json`; incidentally there's also `application/hal+xml` for the XML variant. Or as someone else rightly suggested, consider just using JSON-LD.

anshou- 9y ago
It's worth pointing out that any valid JSON value is a valid JSON document. There is no requirement or guarantee that an array or an object are the top-level value in a JSON document. "I am a valid JSON document. So is the Number below, and in fact every line below this line." 4 null
- niftich 9y ago
  true
- mstade 9y ago
  You're right, thanks for the correction! Also kind of reinforces my point I feel. That any JSON document is just that, a JSON document; it doesn't carry more semantics just because you say so. My JSON parser will still just see simple JSON values, no matter how much I tell it that a certain key should really be a URL, not just a string.
  - tghw 9y ago
    True, but that's also true of any XML, RSS, Atom, HTML, etc. Websites abuse HTML all the time, and there's nothing saying that just because something is transferred with application/atom+xml that it will be valid or follow the spec. It's more of a social agreement. If you get a JSON object from a place you expect a JSON Feed and it has a title and items, then it'll probably work, even if it omits other things.

CharlesW 9y ago

Dave Winer (the creator of RSS) played with this a bit in 2012. It turns out that exact format of feeds doesn't matter nearly as much as there being a more-or-less universal one. http://scripting.com/stories/2012/09/10/rssInJsonForReal.html http://scripting.com/stories/2012/09/10/rssInJsonForReal.htm...

AceJohnny2 9y ago
I'm sure there's... oh of course: https://xkcd.com/927/ https://xkcd.com/927/ (and I realize this doesn't exactly map, as JSON Feed isn't even trying to cover all the usecases of Atom or RSS, just switching the container format)

gumby 9y ago

A good announcement explains what problem it is intending to solve.

ozten 9y ago

XML is aweful, but it does have CDATA, which lets you embed blog posts directly and it's easy to debug. String encoded blog posts are going to be painful once people start using the `content_html` part of the spec.

__david__ 9y ago
Naw, JSON has reasonable quoting in the strings. It's maybe painful to read the raw json, but it encodes just fine.

gedrap 9y ago

But does it solve any actual problems other than 'XML is not cool', problems big enough to deserve a new format? It's true that JSON is easier to deal with than XML. But that's relative, there are plenty of decent tools around RSS. From readers, to libraries in the most common programming languages, and extensions in the most common content management systems. JSON is slightly easier to read for human (although that's subjective), but then how often do you need to read the RSS feed manually, unless you are the one who is writing those libraries, etc. But that's a tiny share of all people using RSS. >>> It reflects the lessons learned from our years of work reading and publishing feeds. Sounds like the author(s) has extensive experience in this field and knows things better than some random person on the internet (me). But the homepage of the project doesn't convey those learned lessons.

tannhaeuser 9y ago
Yes JSON is much easier to parse than XML, and is preferred when it fits such as for most Web API requests and responses. However, SGML and XML were invented as structured markup languages for authoring of rich text documents by humans, for which JSON is unsuited and sucks just as much as XML sucks for APIs. Edit: though XML has its place in many b2b and business-to-government data exchanges (financial and tax reporting, medical data exchange, and many others) where a robust and capable up-front data format specification for complex data is required

jawns 9y ago

> It's at version 1, which may be the only version ever needed. Wow. Now that's confidence. Have you ever read the first version of a spec and thought, "That's just perfect. Any additional changes would just be a disappointment compared with the original"?

smacktoward 9y ago
"Now it belongs to the ages!"
Johnny_Brahms 9y ago
MIDI 1.0 is maybe not perfect, but it is still unchanged since 1983. People have tried to replace it for 2 decades, but failed to provide any enhancements worth a switch. But MIDI doesn't really fit that description since it builds on 2 years of work by Roland. My best bet though.
efsavage 9y ago
Unsurprising as this is clearly an ego play, given that the first thing they want you to know is their names.
vanderZwan 9y ago
In all fairness, they're taking a more or less solved problem (feeds), so they don't really have to figure things out there, and they're porting this established solution to a very well-established technology (JSON), so also don't really have to figure stuff out in that sense either. As far as scenarios where it's feasible to get the answer right the first time go, this is a reasonably realistic one. EDIT: Also, if you scroll to the bottom of the page you can see they have let a whole bunch of people look at the spec before releasing it, so there has been at least some peer review.

0x006A 9y ago

why is it size_in_bytes and duration_in_seconds as opposed to content_text and content_html It should just be size and duration or size_bytes size_seconds (but adding units only makes sense if you could use other units). adding _in to the mix is strange.

smilbandit 9y ago

I'd like to see a language available at the item level. You can derive the language from the http headers but if you're dealing with linkblogs it would be nice at the item level to help with filtering. I think that images and urls would do well as order lists rather than as individual values. at the top level you have 3 urls and an array for hubs. with type and url you could have an array for hubs and the urls. same could be done for images at the top level and both again at the item level.

niftich 9y ago

It's unfortunate that XML has fallen so out of favor that well-made, strongly-schemad formats specified in XML, like Atom, are suffering in turn -- although reasons for feeds' demise go well beyond its forms-on-the-wire. This trend frustrates me, but it's undeniable that a lot of web data interchange happens with JSON-based formats nowadays, and the benefits of network effects, familiarity, and tooling support make JSONification worth exploring. But even more frustrating is when a format comes out that's close to being a faithful translation of an established format, but makes small, incompatible changes that push the burden of faithful translation onto content authors, or the makers of third-party libraries. I honestly don't intend to offer harsh targeted critique against the authors -- I assume good faith; more just voicing exasperation. There have been similar attempts over the years -- one from Dave Winer, the creator of RSS 0.92 and RSS 2.0, called RSS.js [1], which stoked some interest at first [2]; others by devs working in isolation without seeming access to a search engine and completely unaware of prior art; some who are just trying something unrelated and accidentally produce something usable [3]; finally, this question pops up from time to time on forums where people with an interest in this subject tend to congregate [4]. Meanwhile, real standards-bodies are off doing stuff that reframes the problem entirely [5] -- which seems out-of-touch at first, but I'd argue provides a better approach than similar-but-not-entirely-compatible riff on something really old. And as a meta, "people who use JSON-based formats", as a loose aggregate, have a serious and latent disagreement about whether data should have a schema or even a formal spec. In the beginning when people first started using JSON instead of XML, it was done in a schemaless way, and making sense of it was strictly best-effort on part of the receiving party. Then a movement appeared to bring schemas to JSON, which went against the original reason for using JSON in the first place, and now we're stuck with the two camps playing in the same sandbox whose views, use-cases, and goals are contradictory. This appears to be a "classic" loose JSON format, not a strictly-schemad JSON format, not even bothering to declare its own mediatype. This invites criticism from the other camp, yet the authors are clearly not playing in that arena. What's the long-term solution here? [1] http://scripting.com/stories/2012/09/10/rssInJsonForReal.html http://scripting.com/stories/2012/09/10/rssInJsonForReal.htm... [2] https://core.trac.wordpress.org/ticket/25639 https://core.trac.wordpress.org/ticket/25639 [3] http://www.giantflyingsaucer.com/blog/?p=3521 http://www.giantflyingsaucer.com/blog/?p=3521 [4] https://groups.google.com/forum/#!topic/restful-json/gkaZl3AtiPk https://groups.google.com/forum/#!topic/restful-json/gkaZl3A... [5] https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/

zeveb 9y ago

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html "Hello, world!") (url https://example.org/initial-post)))) This looks much nicer IMHO than their first example: { "version": "https://jsonfeed.org/version/1", "title": "My Example Feed", "home_page_url": "https://example.org/", "feed_url": "https://example.org/feed.json", "items": [ { "id": "2", "content_text": "This is a second item.", "url": "https://example.org/second-item" }, { "id": "1", "content_html": "Hello, world!", "url": "https://example.org/initial-post" } ] }

foxhill 9y ago
beauty is in the eye of the beholder - i personally prefer the JSON.
JoelSanchez 9y ago
There's EDN, which is to Clojure what JSON is to JS: a format close to the language's way of representing data. https://github.com/edn-format/edn https://github.com/edn-format/edn Example: https://github.com/milikicn/activity-stream-example/blob/4dbc15364dbf636ecf8500b2c2ae4a16bbdd73f9/resources/migrations/activity_streams/seed/data.edn https://github.com/milikicn/activity-stream-example/blob/4db... Not S-expression-based, though.
krapp 9y ago
It looks nicer if you happen to like s-expressions. But to me, it's just replacing one flavor of clutter for another. The best reason not to prefer s-expressions to JSON, though, would be simply that one is already natively supported in browsers and the other would need a parser written in a language that already parses JSON.
9y ago

cocktailpeanuts 9y ago

Doesn't Wordpress already have something like this? http://v2.wp-api.org/ http://v2.wp-api.org/ I don't understand why suddenly people treat this like something that uniquely solves a problem. Maybe I'm missing something?

yoz-y 9y ago
This format is more akin to RSS than to a programmatic rest API. The main goal is to be able to avoid the pitfalls of parsing Atom and RSS feeds. Both Brent Simmons and Manton Reece are quite active in making decentralized alternatives for self publishing for which RSS is the current backbone.
- donohoe 9y ago
  Parsing RSS and Atom feeds is a solved problem, no?
  - yoz-y 9y ago
    JSON Feed is a new solution for the problem already solved by RSS or Atom. It makes it easier to develop new publishers and consumers. It also tackles the main problems with these two formats, e.g.: no realtime subscriptions, mandatory titles which are a pain for microblogs, potential security problems with XML and so on. Like somebody somewhere has written: If no one had ever reinvented the real wheel - our cars would be rolling around on big wooden logs

russellbeattie 9y ago

For anyone who's tried to write a real-world RSS feed reader, this format does little to solve the big problems the newsfeeds have: * Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely. * Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries, clients are forced to use HTTP headers to check last updates, then do a delta on the entire feed if there is new or updated content. Also, if you missed 10 updates, and the feed only contains the last 5 items, then you lose information. This is the nature of a document-centric feed meant to be served as a static file. But it's 2017 now, and it's incredibly rare that a feed isn't created dynamically. A new feed spec should incorporate that reality. * Complete understanding of modern content types besides blog posts? Miss. The last time I went through a huge list of feeds for testing, I found there were over 50 commonly used namespaces and over 300 unique fields used. RSS is used for everything from search results to Twitter posts to Podcasts... It's hard to describe all the different forms of data it can be contain. The reason for this is because the original RSS spec was so minimal (there's like 5 required fields) so everything else has just been bolted on. JSONFeed makes this same mistake. * An understanding that separate but equal isn't equal. Miss. The thing that http://activitystrea.ms http://activitystrea.ms got right was the realization that copying content into a feed just ends up diluting the original content formatting, so instead it just contains metadata and points to the original source URL rather than trying to contain it. If JSONFeed wanted to really create a successor to RSS, it would spec out how to send along formatting information along with the data. It's not impossible - look at what Google did with AMP: They specified a subset of formatting options so that each article can still contain a unique design, but limited the options to increase efficiency and limit bugs/chaos. This stuff is just off the top of my head. If you're going to make a new feed format in 2017, I'm sorry but copying what came before it and throwing it into JSON just isn't enough.

hboon 9y ago
FWIW, This is by Manton Reece and Brent Simmons. And Simmons is known (among other things) as the creator of NetNewsWire which has been around for more than 15 years. He does know a bit about Atom and RSS feeds. https://en.wikipedia.org/wiki/NetNewsWire https://en.wikipedia.org/wiki/NetNewsWire

eric_the_read 9y ago

A few thoughts on the spec itself: * In all cases (feed and items), the author field should be an array to allow for feeds with more than one author (for instance, a podcast might want to use this field for each of its hosts, or possibly even guests). * external_url should probably be an array, too, in case you want to refer to multiple external resources about a specific topic, or in the case of a linkblog or podcast that discusses multiple topics, it could link to each subtopic. * It might be nice if an item's ID could be enforced to a specific format, even if perhaps only within a single feed. Otherwise it's hard to know how to interpret posts with IDs like "potato", 1, null, "http://cheez.burger/arghlebarghle" http://cheez.burger/arghlebarghle"

derefr 9y ago
> a podcast might want to use this field for each of its hosts, or possibly even guests I'm going to pretend this is about music artists in a music library, but the logic is exactly the same for podcast hosts: You tend to want fields like this to be singular, so that the field can be used in collation (i.e. "sort by artist.") If you have multiple artists for a track, usually one can be designated the "primary" artist—the one that people best know, and would expect to find the track listed under when looking through their library. Usually, then, the rest get tacked on in the field in a freeform, maybe comma-and-space delimited fashion. The field isn't a strict strongly-typed references(Person) field, after all; it's just freeform text describing the authorship. But as for hosts vs. guests, that's a whole can of worms. Look at the ID3 standard. Even though music library-management programs usually just surface an "Artist" field, you've actually got all of these separate (optional) fields embedded in each track: • TCOM: Composer • TEXT: Lyricist/Text writer • TPE1: Lead performer(s)/Soloist(s) • WOAR: Official artist/performer webpage • TPE2: Band/orchestra/accompaniment • TPE3: Conductor/performer refinement • TPE4: Interpreted, remixed, or otherwise modified by • TENC: Encoded by • WOAS: Official audio source webpage • TCOP: Copyright message • WPUB: Publishers official webpage • TRSN: Internet radio station name • TRSO: Internet radio station owner • WORS: Official internet radio station homepage That gives you separate credits for pretty much the entire composition, production and distribution flow, which usually means that each field only needs one entry. Would be great if people used them, wouldn't it? Maybe the semi-standard "A feat. B (C remix)" microformat could be parsed into "[TPE2] feat. [TPE1] ([TPE4])"...

ehosca 9y ago

stopped reading after "JSON is simpler to read and write, and it’s less prone to bugs." ....

ttepasse 9y ago

Shortly after RSS 0.9 came out RSS 1.0 reformulated the RSS vocabulary in RDF terms. Of course the modern (sane) successor to RDF/XML is JSON-LD. So I'm hoping for JSON-LD Feed 1.1 and a new war of format battles. Maybe we can even get Mark Pilgrim out of hiding!

toyg 9y ago
Someone should open a social network for feed-wars veterans. More seriously, it's sad so to see that almost 20 years later, the dream of a decentralised and bidirectional web is in even worse shape than it was back then.
- bullen 9y ago
  Yes, extend this to JSON pingback and bring back the decentralized social web.

donohoe 9y ago

I have grave concerns that this publishing format is delivered to us by two people that, as far as I can see, have limited to zero publishing background. That said, they're being responsive to questions in Issues, so I remain optimistic.

acdha 9y ago
Learning about the history of RSS should alleviate your concerns. Brent Simmons has been working in the space for 15 years, writing one of the more popular clients and working at a company which provided sync and syndication services: https://en.wikipedia.org/wiki/NetNewsWire#History https://en.wikipedia.org/wiki/NetNewsWire#History

Communitivity 9y ago

It is worth pointing out that there is a relevant W3C Recommendation "JSON Activity Streams", https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/ . I'm not saying JSON Feed is worse, or better. I am saying that I think JSON Feeds adoption requires a detailed comparison between JSONFeed and JSON Activity Streams 2.0.

smilbandit 9y ago
Thanks +1, didn't know that.

pedalpete 9y ago

"JSON has become the developers’ choice for APIs", I'm curious about how people feel about this statement from a creation vs consumption perspective. I'm currently creating an API where I'm asking devs to post JSON rather than a bunch of separate parameters, but I haven't seen this done in other APIs (if you have, can you point me to a few examples?). I'm curious what others thoughts are on this. It seems that with GraphQl, we're maybe starting to move in this direction.

systematical 9y ago

Who uses feeds? Who uses XML?

gwu78 9y ago

Is this a "JSON Feed" from NYTimes? Example below filters out all URLs for a specific section of the paper. test $# = 1 ||exec echo usage: $0 section curl -o 1.json https://static01.nyt.com/services/json/sectionfronts/$1/index.jsonp exec sed '/\"guid\" :/!d;s/\",//;s/.*\"//' 1.json I guess SpiderBytes could be used for older articles? Personally, I think a protocol like netstrings/bencode is better than JSON because it better respects the memory resources of the user's computer. Every proposed protocol will have tradeoffs. To me, RAM is sacred. I can "parse" netstrings in one pass but I have been unable to do this with a state machine for JSON. I have to arbitrarily limit the number of states or risk a crash. As easy as it is to exhaust a user's available RAM with Javascript so too can this be done with JSON. Indeed they go well together.

bullen 9y ago

I miss the distributed social pingback days! Implemented: http://sprout.rupy.se/feed?json http://sprout.rupy.se/feed?json

thibaudgg 9y ago

Just added JSON feed support to https://applefocus.com https://applefocus.com (https://applefocus.com/feed.json https://applefocus.com/feed.json), JSON FTW!