Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

181–190 of 225 posts

Re: JSON Feed

#181

Post by Johnny_Brahms »

hajile wrote: post #168
zeveb wrote: post #76

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.or…

Those two aren't comparable because you cannot distinguish between key:val pairs and lists. You need dotted lists.

There is of course sxml, which is more or less well-defined. But that would probably suffer from the same problems as xml, since it is just xml written as s-expressions.

There is one pretty damn solid SSAX parser by Kiselyov that has been ported to just about every scheme out there. It is interesting since it doesn't do the whole callback thing of most ssax parsers, but is implemented as a tree fold over the xml structure.

Re: JSON Feed

#182

Post by dabeeeenster »

pfranz wrote: post #47
mindcrime wrote: post #2

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.

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 see…

What language are you using that doesn't have a working XML parser? REALLY?

Re: JSON Feed

#183

Post by mstade »

eriknstr wrote: post #180
mstade wrote: post #26

> 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 do…

Absolutely agree about the MIME type. Someone filed an issue and created a pull-request for this after you wrote this comment. https://github.com/brentsimmons/JSONFeed/issues/22 https://github.com/brentsimmons/JSONFeed/pull/23 I hope they will merge it.

That's great, thanks for sharing!

Re: JSON Feed

#184

Post by draegtun »

zeveb wrote: post #76

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.or…

JSON was influenced by Rebol, which i feel would provide an even nicer 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
        ]
    ]

Re: JSON Feed

#185

Post by mattmanser »

dabeeeenster wrote: post #182
pfranz wrote: post #47

Earlier quoted context omitted.

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 see…

What language are you using that doesn't have a working XML parser? REALLY?

He said appropriate XML parser.

All languages have XML parsers, it's more that a lot suck, they might have weird concepts you have to use, or are constantly tripping you up with namespaces, or make it really hard to write xpath queries.

Re: JSON Feed

#186

Post by icebraining »

weberc2 wrote: post #110
morgante wrote: post #37

Earlier quoted context omitted.

Most XML parsers I've used are leaky abstractions. Even once the document is parsed, actually accessing the data can require a lot more complexity than accessing parsed JSON data.

IIRC, the popular C++ implementations were glorified tokenizers. It was up to you to figure out which tokens were data and how those tokens related to each other.

Ah, SAX. People built some true horrors with that API, just because it was "more performant" than DOM. Never mind that their hacked-together tree builders often leaked like sieves.

Re: JSON Feed

#187

Post by revelation »

mindcrime wrote: post #2

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.

Yeah this is great, now instead of properly machine-readable and verifiable XSD files we have pseudo-RFC text on some shitty GitHub page.

Re: JSON Feed

#188

Post by yoz-y »

cocktailpeanuts wrote: post #93

Doesn't Wordpress already have something like this? 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?

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.

Re: JSON Feed

#189

Post by icebraining »

stephenr wrote: post #177
robgibbons wrote: post #167

Earlier quoted context omitted.

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.

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

Nitpick: REST is very well defined. It's not just a protocol, like some people insist.

Other than that, fully in agreement.

Re: JSON Feed

#190

Post by yoz-y »

nothrabannosir wrote: post #113
hboon wrote: post #103

Earlier quoted context omitted.

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

Ok, I have no idea who these guys are so forgive me being rude: if they're so good then why did they not address those points? to my eyes, op makes a solid argument. I'd like to know their side of the story.

But they did...

> Badly formed XML? Check. There might be badly formed JSON, but I tend to think it'll be a lot less likely.

The problem with XML is mostly that it is a very complex format so the bugs are more probable and there are more pitfalls.

> Need to continually poll servers for updates? Miss. Without additions to enable pubsub, or dynamic queries ...

They actually did add tags to enable WebSub (previously called pubsub) so there goes that. For the other concerns, I think it is not the formats job to care for partial or incomplete data. Nothing prevents you to have a dynamic link with a "updatesSince" on your webpage and serve all of the articles that were added or updated after that. Nowhere, the format specifies the limit on number of items. It also incorporates paging out of the box so you could bubble up any old articles.

> Complete understanding of modern content types besides blog posts? Miss.

The point of this is for the open web, by definition nobody can anticipate all formats. Rather than fill the spec with tweets, facebook and other types, they have opted for the least common denominator and added a specific way to add extensions. This makes way more sense.

* An understanding that separate but equal isn't equal. Miss.

Nothing actually prevents you to leave the content fields blank and rely on the reader to pull the format. But for this kind of usage there are other methods. Personally I prefer content delivered in the RSS precisely to avoid to have to deal with customization of content formatting. JSON feed HAS a way to specify formatting though, it's called HTML tags. No need to reinvent the wheel here.

Post reply on HN