Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

Post reply on HN
Print view View original

91–100 of 168 posts

Re: JSON Canvas – An open file format for infinite canvas data

#91

Post by samatman »

asa400 wrote: post #85
exceptione wrote: post #78

Earlier quoted context omitted.

SQLite has no real types. Use SQLite if data quality is of no concern. The applicability domain of SQLite is far smaller than people think. If you want to improve on JSON, you would have to go into an other direction. Maybe something like postgis would be helpful for extremely large canvasses. JSON Schema is pretty powerful by the way. Checkout the documentation. SQLite is absolutely no match there. What Sqlite could…

SQLite's types are quite loose by default, no doubt. There is a somewhat recent STRICT mode that strengthens them: https://www.sqlite.org/stricttables.html

Exactly so. SQLite also has a rich collection of CHECK constraints which can raise errors if data is not to your liking in some fashion, this includes validating JSON. Not a JSON schema, admittedly, although (just like for Postgres) this is available as an extension. https://github.com/asg017/sqlite-jsonschema

Saying that SQLite doesn't have "real types" is simply false. If one doesn't want to learn how to use a tool, blaming it for that failure is poor form.

Re: JSON Canvas – An open file format for infinite canvas data

#92

Post by tonyarkles »

dekhn wrote: post #26

Is this infinite canvas similar to QGraphicsView? I've been looking for a good equivalent to QGraphicsView and HTML Canvas is not it (HTML Canvas is a raster image, QGraphicsView is a size-independent fixed-sized, scrollable canvas with indexed objects).

Would it be possible to bang SVG into what you’re looking for? It’s a little bit quirky but I’ve used it to draw some pretty wild diagrams with a small amount of JS for pan and zoom.

Re: JSON Canvas – An open file format for infinite canvas data

#93

Post by bbkane »

cstrahan wrote: post #88
desmondl wrote: post #76

Earlier quoted context omitted.

I haven’t had any issues with yaml in markdown frontmatter or openapi specs. What kind of issues do you see with list and maps that make you against yaml? I agree that for computers and consistency json is preferred. I already use a linter for my markdown files so I would do the same with yaml to keep lists and maps consistent

YAML is kind of like C++: > You like C++ because you're only using 20% of it. And that's fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20% :) https://eli.thegreenplace.net/2009/10/17/the-c-bashing-seaso... The YAML footguns are too numerous to reproduce here, so here are some sources: https://stackoverflow.com/questions/3790454/how-do-i-break-a... https://www.arp242.net/yaml-confi…

Point taken, but you can mitigate a lot of this with yamllint.

Re: JSON Canvas – An open file format for infinite canvas data

#94

Post by louthy »

desmondl wrote: post #48
kepano wrote: post #15

Whoa! Didn't expect this to bubble up to the top of HN. Some context about why we created JSON Canvas: https://obsidian.md/blog/json-canvas/ We just released it today, so this is still a very nascent project. A little over a year ago we released Obsidian Canvas. The .canvas file format has felt stable enough to give it a name and resources that other apps can freely use. See the original Show HN: https://news.ycombin…

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf). JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of i…

> I agree with a lot of comments that it's minimal, but in my opinion that is a good thing

The purpose of a spec is to specify, and if you don’t specify and leave things open to interpretation, then that completely defeats the purpose.

Anybody who’s worked with a poorly defined spec knows exactly how bad this can be. A good example would be the shambles that is the HL7 spec used in healthcare.

A former colleague had a phrase for this: “once you’ve seen one HL7 message… you’ve seen one HL7 message”. Which really highlights the issue of a standard that’s open to interpretation.

The issues raised (in the comments here) seem to hint at a lack of specificity. That is something that they should really look at improving.

I think overall any group that tries to come up with a standard that can unify a field should be lauded and supported. But perhaps calling this a 0.1 release, and taking the feedback on board, would be the best way forward.

Re: JSON Canvas – An open file format for infinite canvas data

#95

Post by npunt »

eichin wrote: post #83
remram wrote: post #34

Earlier quoted context omitted.

Who was involved in this open spec? Or was it built by Obsidian with a hope that it works for everyone else? Which existing formats were considered before building your own, e.g. SVG/Excalidraw/draw.io/...?

Yeah, didn't see any discussion in the other thread, do you have any notes on why this isn't SVG?

It makes sense if you see Obsidian as the starting point - it's a document store. While other canvas products may be more graphics-oriented, Obsidian's is about laying out documents and objects and providing simple relationships between them. For this purpose, JSON's probably a lot easier to work with than XML/SVG.

Re: JSON Canvas – An open file format for infinite canvas data

#96

Post by darkteflon »

How interesting. I was just this weekend looking to implement a DAG/multitree-based tasks app as a side project, and my first thought was to do it as an obsidian plugin with D3 for rendering. I ended up canning that idea because it felt like a bridge too far to cram nodes and links into a human-readable format like markdown. I went with SQLite and a TUI instead. Seeing this spec emerge makes me think that Obsidian might be a good place for that kind of plugin after all. It’s becoming something of an emacs, Obsidian is!

Re: JSON Canvas – An open file format for infinite canvas data

#98

Post by exceptione »

samatman wrote: post #91
asa400 wrote: post #85

Earlier quoted context omitted.

SQLite's types are quite loose by default, no doubt. There is a somewhat recent STRICT mode that strengthens them: https://www.sqlite.org/stricttables.html

Exactly so. SQLite also has a rich collection of CHECK constraints which can raise errors if data is not to your liking in some fashion, this includes validating JSON. Not a JSON schema, admittedly, although (just like for Postgres) this is available as an extension. https://github.com/asg017/sqlite-jsonschema Saying that SQLite doesn't have "real types" is simply false. If one doesn't want to learn how to use a tool…

The author of SQLite is quite open about it. The lack of typing has been part of the design from the beginning. Sqlite has hardly any types:

    INT
    INTEGER
    REAL
    TEXT
    BLOB
    ANY
Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript.

Unfortunately, that is not the same as typing. Sqlite lacks typing because, as the sqlite author explains in the docs, flexibility is the goal. He continues with "But other developers are aghast", and so strict tables where born, but you can clearly see this cannot overcome real concerns. Try to look for the DATETIME datetype in that list.

Deep bow to sqlite, its design goal was to be the ini file replacement and it has outperformed itself on that one.

Thanks for the extension link. Although constraints are not reuable type definitions, they would still be helpful in this context. Pity that json doesn't have a type for dates, one has to rely on string formats: https://json-schema.org/understanding-json-schema/reference/...

Post reply on HN