21–30 of 225 posts
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.
This seems like a great idea. If it can help even one developer it's worth it.
Or asked another way, what problem does this solve for you?
Earlier quoted context omitted.
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?
Mind sharing?
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.
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.
> 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
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.
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.
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.
No, please don't.
Earlier quoted context omitted.
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.