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

221–225 of 225 posts

Re: JSON Feed

#221

Post by bullen »

toyg wrote: post #147
ttepasse wrote: post #119

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!

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.

Yes, extend this to JSON pingback and bring back the decentralized social web.

Re: JSON Feed

#222

Post by yoz-y »

russellbeattie wrote: post #205
yoz-y wrote: post #190

Earlier quoted context omitted.

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

I don't agree with most of what you wrote, but the "it's called HTML tags" is the most wrong. You must not have tried this any time in the past 5 years or so. The embedded tags come out of CMSs and - when they're not stripped completely - look like and . HTML isn't used alone, it's always used with CSS nowadays, and no matter if semantic tags are best practice, the fact is it's optional and regularly not used. If the…

What is the difference between re-publishing the content in some other format which will do formatting well and re-publishing the content using sensible html tags with maybe some embedded minimal stylesheet?

There might be mis-use and abuse, but if you want to avoid that you can always push markdown into the "text" representation.

Re: JSON Feed

#223

Post by hajile »

zeveb wrote: post #204
hajile wrote: post #168

Earlier quoted context omitted.

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

Nope, one would normally write the code which parses such S-expressions such that the first atom in each list indicates the function to use to parse the rest of the list. So there'd be a FEED-FEED function which knows that a feed may have version, homepage URL &c., and there'd be a FEED-ITEMS function which expects the rest of its list to be items, a FEED-ITEMS-ITEM function which knows about the permissible componen…

In the absolute abstract, you are correct. In the absolute abstract, you could replace parens with significant whitespace and have zero visible syntax.

In practice, lisp adopted dotted lists 60 years ago and basically every lisp since has used it as one way to represent an associated list. Minimal syntax is better than zero syntax or loads of syntax.

Re: JSON Feed

#224

Post by rspeer »

jancsika wrote: post #219
rspeer wrote: post #211

Earlier quoted context omitted.

Well, there's JSON-LD (JSON Linked Data) already. It's for making interoperable APIs, so there is a good motivation for namespaces. But the namespaces are much less intrusive than XML namespaces. Ordinary API consumers don't even have to see them. One of the key design goals of JSON-LD was that -- unlike its dismal ancestor, RDF/XML -- it should produce APIs that people actually want to use.

Thanks, I haven't explored JSON-LD before. But that's not a case of adding namespaces to JSON, is it? What I mean is if one were to take the skeptical position that JSON is going to end up "re-inventing the XML wheel", that would mean JSON advocates would need to push namespaces into the JSON spec as a core feature of the format. I've never read a discussion of such an idea, but I'd like to if they exist. edit: clari…

Well, yeah, perhaps the craziest thing about XML is that it has namespaces built into its syntax with no realistic model of how or why you would be mashing up different sources of XML tags.

Namespaces are about the semantics of what strings refer to. They belong in a layer with semantics, like JSON-LD, not in the definition of the data transfer format.

I am convinced that nobody would try to add namespaces to JSON itself. Just about everyone can tell how bad an idea that would be.

Re: JSON Feed

#225

Post by jancsika »

rspeer wrote: post #224
jancsika wrote: post #219

Earlier quoted context omitted.

Thanks, I haven't explored JSON-LD before. But that's not a case of adding namespaces to JSON, is it? What I mean is if one were to take the skeptical position that JSON is going to end up "re-inventing the XML wheel", that would mean JSON advocates would need to push namespaces into the JSON spec as a core feature of the format. I've never read a discussion of such an idea, but I'd like to if they exist. edit: clari…

Well, yeah, perhaps the craziest thing about XML is that it has namespaces built into its syntax with no realistic model of how or why you would be mashing up different sources of XML tags. Namespaces are about the semantics of what strings refer to. They belong in a layer with semantics, like JSON-LD, not in the definition of the data transfer format. I am convinced that nobody would try to add namespaces to JSON it…

> Well, yeah, perhaps the craziest thing about XML is that it has namespaces built into its syntax with no realistic model of how or why you would be mashing up different sources of XML tags.

The thing that gets me is that they were added to XML, so the downstream APIs then got mirrored interfaces like createElementNS and setAttributeNS that cause all sorts of subtle problems. With SVG, for example, this generates at least two possible (and common) silent errors-- 1) the author creates the SVG in the wrong namespace, and/or 2) more likely, the author mistakenly sets the attribute in the SVG namespace when it should be created in the default namespace. These errors are made worse by the fact that there is no way to fetch that long SVG namespace string from the DOM window (aside from injecting HTML and querying the result)-- judging from Stackexchange users are manually typing it (often with typos) into their program and generating errors that way, too.

Worse, as someone on this site pointed out, multiple inline SVGs can still have attributes that easily suffer from namespace clashes in the section. It's almost comical-- the underlying format has a way to prevent nameclashes with multiple attributes inside a single tag that share the same name-- setAttributeNS-- but is no help at all in this area.

edit: typo and clarification

Post reply on HN