Live data from Hacker News

JSON Feed

jsonfeed.org

11–20 of 225 posts

Re: JSON Feed

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

Re: JSON Feed

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

Re: JSON Feed

#13
post #4

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

JSON parsers have a much smaller 'feature surface' meaning that there are fewer nooks and crannies for bugs to live in. One example of a bug that often festered in XML parsers: https://en.wikipedia.org/wiki/Billion_laughs (there is no JSON equivalent of this) The generalized theory, for those interested : https://en.wikipedia.org/wiki/Rule_of_least_power

What from I grok the guy requesting JSON-LD wants this functionality

Re: JSON Feed

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

Re: JSON Feed

#15
post #5

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.

We don't prefer JSON to XML for any reason other than that XML is terrible by comparison.

That's not a reason.

Re: JSON Feed

#16
post #7
post #4

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

RSS is sometimes ambiguous and there's a lot of variation. It can be hard to parse correctly. Not sure about Atom, though.

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

Re: JSON Feed

#17
post #8
post #4

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

Probably this part: > simpler to read and write

If you're writing these things by hand, you're probably doing something wrong...

Re: JSON Feed

#18
post #4

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

Consider XML entity bombs. You need to explicitly tell your XML parser not to follow the spec to prevent malicious sources of XML from crashing your application. XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not.

Re: JSON Feed

#20
post #5

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.

We don't prefer JSON to XML for any reason other than that XML is terrible by comparison.

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.
Post reply on HN