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

151–160 of 225 posts

Re: JSON Feed

#151

Post by d0mine »

jameshart wrote: post #128
anshou- wrote: post #41

Earlier quoted context omitted.

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

Actually actually... the JSON spec doesn't define the concept of a JSON document. Neither http://www.json.org/ nor http://www.ecma-international.org/publications/files/ECMA-ST... actually specifies that a JSON 'document' is synonymous with a JSON 'value'. Now it's also true that JSON doesn't specify an entity that can be either an object or an array but not be a string or a bool or a number or null. So it's kind of t…

Why are you referencing the obsolete rfc? There is no restriction to object/array for the JSON text in the current rfc https://tools.ietf.org/html/rfc7159

Re: JSON Feed

#152

Post by hyperpallium »

anshou- wrote: post #41
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…

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

false

Re: JSON Feed

#153

Post by hyperpallium »

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.

In practice, json is much easier to work with on the command line because of jq.

Re: JSON Feed

#154

Post by derefr »

eric_the_read wrote: post #112

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

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

Re: JSON Feed

#155

Post by pedalpete »

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

Re: JSON Feed

#156

Post by hyperpallium »

falcolas wrote: post #96
hayleox wrote: post #88

Earlier quoted context omitted.

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/ ) and have a bash script hacked together in 10 minutes to do whatever I want with the feed.

I give you libxml: xmllint --xpath '//element/@attribute' There's a good chance it's already installed on your mac.

To avoid the hassle of handling xml namespaces (e.g. in an Atom feed...), just do:

    xmllint --xpath '//*[local-name()="element"]/@attribute'
Note: for consistency, namespaces are not needed for attribute names.

http://stackoverflow.com/questions/4402310/how-to-ignore-nam...

Re: JSON Feed

#157

Post by jack9 »

mindcrime wrote: post #140
weberc2 wrote: post #108

Earlier quoted context omitted.

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.

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.

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.

Re: JSON Feed

#158

Post by bastawhiz »

josteink wrote: post #83
bastawhiz wrote: post #18

Earlier quoted context omitted.

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.

> XML also has a lot of room for syntax errors, No it doesn't. XML is either well formed or not, and any parser encountering non well-formed XML will reject it outright. Therefor all XML in use on the internet is spec-compliant. Now try to say the same about JSON.

> any parser encountering non well-formed XML will reject it outright.

Ah, I see you're new to parsing XML.

Re: JSON Feed

#159

Post by bastawhiz »

jjawssd wrote: post #35
bastawhiz wrote: post #18

Earlier quoted context omitted.

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.

> XML also has a lot of room for syntax errors, with many types of tokens and escape rules. JSON, by comparison, does not. Parsing JSON is a minefield. Yellow and light blue boxes highlight the worst situations for applications using the specified parser. Take a look at how a bunch of parsers perform with various payloads: http://seriot.ch/json/pruned_results.png "JSON is the de facto standard when it comes to (un)se…

Parser correctness is irrelevant when you're talking about the ability to be written with few syntax errors. For instance, JSON has one type of string with one set of string escape rules. XML has element names, attribute names, attribute values, text nodes, CDATA content, RCDATA content, and more. And almost all of them have different rules for what they can contain and how they can be used.

By comparison, XML is orders of magnitude more complex than JSON.

Post reply on HN