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

141–150 of 168 posts

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

#141

Post by SQLite »

eviks wrote: post #132
mch82 wrote: post #108

Earlier quoted context omitted.

The SQLite docs have a great page on the use case `asa400` describes. SQLite as an Application File Format, https://sqlite.org/appfileformat.html

What's the best example of this format used for complex docs, has anyone implemented their OpenDocument replacement idea?

One example: Fossil (https://fossil-scm.org), the version control system used by SQLite itself. Fossil is Git-like in its underlying design but has a different interface. Fossil stores a complete source code repository as an SQLite database, rather than a pile-of-files as Git does. Storing content this way gives Fossil UI advantages over Git, such as the ability to easily find decedents of a check-in, and the ability to assign the same tag to multiple check-ins (ex: tagging every release with the "release" tag.)

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

#142

Post by exceptione »

samatman wrote: post #127
exceptione wrote: post #98

Earlier quoted context omitted.

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, flexi…

> Of course one can program all kind of check constraints, like one can program all kinds of value validations in javascript. I don't consider this a valid distinction where databases are concerned. If you define a datatype in an ordinary SQL database, and try to pass it invalid data, it will fail at runtime. How else could it work? There's no compile-time interaction between the value and the database. If you define…

Types are a contract, that both parties can understand. This notion is not captured by operational semantics.

Parties that do not read the database contract will get caught by runtime validation. However, any code that targets the database contract could make use of that contract, e.g. with scaffolding. This might enable tighter integration with type checking in the client program.

What you propose is not a contract, your code doesn't understand it, so now you introduce a new problem. (I think that is why the sqlite author doesn't seem to be too enthusiastic about bolting on strictness checks, as its potential is really limited and it contradicts its design).

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

#143

Post by Sakos »

DrDeadCrash wrote: post #81
aragonite wrote: post #20

Earlier quoted context omitted.

Check out this video from one of my favoriate infinite canvas softwares, especially beginning around 1:25 (which I'm deep-linking to): https://youtu.be/GblI7GI0jQ4?t=85 (Alas, the original desktop app (iMapping, in Java) as shown in the video is no longer being developed, and now they are only developing the web app (Infinitymaps) only run in the browser, which imo is not the best fit for infinite canvas apps which c…

Imo it would need to show varying levels of information density depending on scale. Otherwise, as another commenter stated it's overwhelming....

One of my favourite implementations is a note-taking app on Android/iOS named ZoomNotes, where you can add a "sub-canvas" anywhere that lets you click into it, taking you into a different infinite canvas. This helped me organize my information better. You could nest canvases as much as you wanted.

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

#144

Post by gjvc »

exceptione wrote: post #90
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

In the past I had to craft yaml files. Sometimes I needed quotes for a string, sometimes I had to put in a dash in front of a key, or just not. You basically needed to have the whole schema in your head. There can only be so much nesting before you lose track of what item belong to which parent. Copying some yaml structures over to another level requires care, as the result might look correct, but the white space par…

JSON5 has comments. This is the major thing. A configuration which does not allow comments is not a configuration for humans, it's a serialization for programs.

CMakePresets.json is an offender here...

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

#145

Post by rootlocus »

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?

Looking at the JSON, I assume this is a higher level format that may output SVG. For instance, the arrows between nodes are defined by reference to node names and node sides. In SVG that would be a hardcoded curve and shape for the arrow which loses the semantic meaning "there's a relation between two nodes", where nodes may also have semantic meaning such as "idea" or "book".

A tool may parse the json canvas file and extract information such as "there are three ideas linked to this book". Another tool may output an SVG.

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

#146

Post by pastage »

asa400 wrote: post #82
desmondl wrote: post #65

Earlier quoted context omitted.

I think you're talking about the trade offs between supporting features like "DOM manipulation, state management, animation, etc." and "shipping updates" out of the box, versus only storing the data as simple files and leaving everything else to the implementation. Sqlite as an application file format is great [1], but for a knowledge base / note taking app the benefits are not worth the tradeoffs in my opinion. Sqli…

> I think you're talking about the trade offs between supporting features like "DOM manipulation, state management, animation, etc." and "shipping updates" out of the box, versus only storing the data as simple files and leaving everything else to the implementation. I'm not sure I understand. Can you clarify? > Sqlite is more performant more performant and provides lots of built-in features. However, most note takin…

> SQLite is self-describing, also. You open `sqlite3` and type .schema

My feeling is that xml and json is always easier to parse than SQL. What I often see is that a large amount of application logic is hidden in how the tables are joined or selected. In SQL this is almost always the case and of course this is often the case in json as well to some extent but usually alot less.

In the end it comes down to that xml was not the end all of integration formats, neither are its replacements. Actually being able to read and understand what you parse without tooling is an immense help.

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

#147

Post by exceptione »

gjvc wrote: post #144
exceptione wrote: post #90

Earlier quoted context omitted.

In the past I had to craft yaml files. Sometimes I needed quotes for a string, sometimes I had to put in a dash in front of a key, or just not. You basically needed to have the whole schema in your head. There can only be so much nesting before you lose track of what item belong to which parent. Copying some yaml structures over to another level requires care, as the result might look correct, but the white space par…

JSON5 has comments. This is the major thing. A configuration which does not allow comments is not a configuration for humans, it's a serialization for programs. CMakePresets.json is an offender here...

Agreed. Json seems to be designed with machine interpretation as first concern. Having to wrap object keys into quotes eases parsing I guess, but for humans it is a nuisance.

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

#148

Post by remram »

rat9988 wrote: post #116
remram wrote: post #115

Earlier quoted context omitted.

Obsidian's own file format might have merit, but posting it as an "open file format", "created to provide (...) interoperability, and extensibility to data created with infinite canvas apps"... and then publishing 1.0 without consulting with anybody else... is rather egregious, I think. I agree with you that posting Obsidian's spec to start the conversation would have been welcome, but this is not what they did.

I'm not sure I agree with you here at all. They can start a format that serves their own purpose, and make it open for interoperability and extensibility sake. Nothing wrong with it.

"egregious" was a strong word, apologies. Still the silence is deafening here.

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

#149

Post by bbkane »

8n4vidtmkvmk wrote: post #136
bbkane wrote: post #93

Earlier quoted context omitted.

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

That's pretty sad that you need to lint your config lang.

I used to feel that way, and in some sense I still do, but in practice it fits right in with my other linters so it's not any trouble.

Config language design seems to have a surprisingly "bumpy" design space, where optimizing for one thing (human readability, or human familiarity, or tooling support, or flat data, or nested data, or strong types, or DRY, etc...) necessitates tradeoffs in other areas.

No wonder there's so many config languages!

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

#150

Post by henrun12 »

I'd love to see this get adoption, I use a few different whiteboarding apps for the different features they offer, but would be great to have more portability between them. e.g. I find tldraw great for creating diagrams, but when I have to share them with people I end up screenshotting and pasting into figma
Post reply on HN