5 ms·
Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting the
by gambler 7y ago
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.
- pfraze 7y agoThere'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.
- grenoire 7y agoThe 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.
- elcomet 7y agoI 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?
- dpe82 7y agoHow do you express "Why didn't you use <img src="xml_has_its_uses.png"> XML!?" with json?
- rolltiide 7y agoyou 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!?"
- grenoire 7y agoOP 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.
- elcomet 7y agoWell 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.
- rolltiide 7y agogain 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
- jazzyjackson 7y agoAssuming 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!?"}} ] }}
- rolltiide 7y agocan 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
- cblades 7y agoNot 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.
- jjdjr0odo7 7y agoOver generalized solutions smells like premature optimization Solve for the problems at hand, not ones we can conceptualize. If a stack works fine, why does the parser picked for that stack need to be anything else than what’s working?
- theamk 7y agoI 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.
- api 7y agoYou also invite degeneration into an imageboard which ends up being a wall of memes and stupid jokes.