Hacker News Reader

Comment by gambler | Hacker News Reader

Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting themselves and their users in the foot. Just because W3C fucked up in some of their XML-based standards doesn't mean that trying to shove JSON everywhere is a sensible idea.

  {
  "topic": "dat://unwalled.garden",
  "body": "Why didn't you use XML!?",
  "createdAt": "2018-12-07T04:15:44.722Z"
  }

Now, I want to change body to include images or something of that sort. Bam, all the software that parses the old format is now broken.

Just use XML. Preferably, extend one of the existing RSS-like formats. Apply lessons learned from HTML and XHTML. It will work zillion times better in the long run.

View on HN

There's nothing stopping you from extending the JSON schema. We'll probably come up with extension points to make it easier (as subobjects, each declaring their own schema IDs).

The format really isn't the interesting question. The interesting question is how do we get clients to behave predictably with each other. If you start breaking the schemas that everyone on the network is using, then yes your posts should fail to render and probably be ignored.

The format is exactly for the purpose of getting clients to behave predictably!

Without defining these schemas to allow for flexible mixed media documents, you're always going to have chaotic implementations floating around.

I think inability to include images it is actually a feature.

As long as your body is a plain text, you can present it in a very wide variety of ways and styles. Once you allow formatting and inline images, you start moving towards HTML documents, and lose consumer's control over content.

You also invite degeneration into an imageboard which ends up being a wall of memes and stupid jokes.

I don't follow you. JSON is very extensible. Just add a new key like "body-image" and you're done.

How is that different from XML if your body is defined as a text field?

How do you express "Why didn't you use <img src="xml_has_its_uses.png"> XML!?" with json?

you don't, you just store the string as is in the body tag and let the client side parser know how to parse html strings that may also include an image tag

what is the argument here? why didn't you know you answered your own question

"body":"Why didn't you use <img src="xml_has_its_uses.png"> XML!?"

OP is asking what the content type of the body is to be interpreted as.

You're assuming HTML string, which might not always be correct. What do you do with Markdown?

You need to have a standard way to represent things like this, because otherwise it won't gain traction solely due to the immense complexity of implementing viewers.

Edit: On top of this, HTML might not necessarily be the best choice. In that case it'd just be browser wrappers galore.

Well grandparent also assumed HTML since he put an HTML tag with html attributes in his node. I'm not sure how different this is, and if he wants to convert this to markdown he'll also need a html to markdown converter.

gain traction? you are really talking about a non-issue this decade

everyone is already used to making their frontend, backend and database parse and store external things in key value pairs

this schema pre-detecting ship has sailed a long time ago

Assuming It's eventually going to be read as HTML I do this

  {"body":{
    "childNodes": [
      {"span":{"textContent":"Why didn't you use "}},
      {"img":{"src":"xml_has_its_uses.png"}},
      {"span":{"textContent":" XML!?"}}
    ]
  }}

can you explain that example more clearly?

if you wanted to "include images or something of that sort" you would add an "images" key or a "something of that sort" key

in your particular example, body can clearly take image links image data as string and the parser can deal with it.

in my projects we typically would have a nosql database which out the box allows it to be indifferent about objects in a collection/table that include or exclude certain keys

Not who you're responding to, but:

>and the parser can deal with it.

That's not ideal. You need a defined schema so that the majority of parsers can reliably parse the majority of objects.

>in my projects we typically would have a nosql database Parser implementations shouldn't be assumed to use the same or similar tech stack that you do.

Reply on news.ycombinator.com