I'm not convinced this is possible. Text is simple which is why it is easy to make multiple editors. Most other things are not.
For example imagine structured drawing programs. Some might support circles, others might support ovals. If the 2nd one writes an oval and the first one doesn't support ovals then it's no longer portable. You can't think of all the features you could possibly want therefore you can't have a portable format. Even for the same features, one app might store a circle as center+radius and another as left corner+right corner of it's bounding box, and yet another as center+widthRadius+heightRadius and another as center+angleOfRotation+2radiuses and another as radius+group(scale/rotation/position)
You can see this issue throughout structured drawing programs. Illustrator,Affinity Design, Inkscape. They might all export/import to SVG but they lose all the data that makes them editable because every app supports different features and or similar features but defined in different ways.
Even pixel image formats are not portable for all the same reasons. Yes you can load/save a PNG from any image editor. But, generally, trying to load the apps own format, the one where it's still in a more editable format, into another editor is at best a lossy feature and usually not supported. It's lossy, because the editor doing the loading doesn't support every feature of the other app. For example, Photoshop supports "smart layers" (layers where the data is not rasterized into the layer but rendered on demand). Those layers can contain PDFs. So your app needs a PDF renderer to load and render them and keep them editable.
Node editors will arguably have all the same issues. The simplest example is that they might all support different widgets inside the nodes. A music node editor might show waves, or knobs. A graphics node editor might show a spinible cube/sphere preview. A node editor for tablets will also likely have a different UX.
I agree that it would be tough to create a uniform standard; there’s at least one library that tries to use/extend SVG features for defining node shapes, and even they admit it’s a PITA and so provide programmatic wrappers: [GoJS Geometry](https://gojs.net/latest/api/symbols/Geometry.html)
They leverage SVG Paths [1] to define node/object shapes, and so you can use Bézier curves and other entities defined in the SVG spec in your graphs [2]. Alternatively you can just reference .svg files. They have a lot of cool samples [3]. I don’t remember where I came across it, but I’ve been digging through github to find the libraries that popular tools use; there are 3k forks, so somebody likes it.
Then you need to have editors specify which features they support and create common standards to make sure that two editors that support the same feature can actually understand each others' encodings of it. It's unfortunately too true that we will never have a single, perfect standard in any domain. It falls upon us to create smaller standards and be explicit in which ones we each dabble in. Otherwise there are no standards at all.
Surely it's no different to how IDEs can support autocomplete and intellisense for multiple languages. Something like a LSP definition would tell the editor what nodes were supported and what the syntax rules were.
Previews and feedback would be the toughest problem - a lot of node editors are very closely tied to rendering (or the equivalent) and real time feedback is common.
But - these are challenges more than they are blockers.
They aren't. For proof I give 50 years of this problem not being solved anywhere except text files effectively because text files have no structure except line feed.
There is no universal format for formatted text. You could point to HTML but try exporting to HTML from Word and then importing back in and you'll see what's missing. There is no universal format for structured graphics. No universal format for raster graphics. No universal format for 3D. No universal format for spreadsheets. Etc.....
They all have the same issue. There are infinite possible features and infinite possible ways to represent those features, each with their own tradeoffs.
I'm not convinced this is possible. Text is simple which is why it is easy to make multiple editors. Most other things are not.
For example imagine structured drawing programs. Some might support circles, others might support ovals. If the 2nd one writes an oval and the first one doesn't support ovals then it's no longer portable. You can't think of all the features you could possibly want therefore you can't have a portable format. Even for the same features, one app might store a circle as center+radius and another as left corner+right corner of it's bounding box, and yet another as center+widthRadius+heightRadius and another as center+angleOfRotation+2radiuses and another as radius+group(scale/rotation/position)
You can see this issue throughout structured drawing programs. Illustrator,Affinity Design, Inkscape. They might all export/import to SVG but they lose all the data that makes them editable because every app supports different features and or similar features but defined in different ways.
Even pixel image formats are not portable for all the same reasons. Yes you can load/save a PNG from any image editor. But, generally, trying to load the apps own format, the one where it's still in a more editable format, into another editor is at best a lossy feature and usually not supported. It's lossy, because the editor doing the loading doesn't support every feature of the other app. For example, Photoshop supports "smart layers" (layers where the data is not rasterized into the layer but rendered on demand). Those layers can contain PDFs. So your app needs a PDF renderer to load and render them and keep them editable.
Node editors will arguably have all the same issues. The simplest example is that they might all support different widgets inside the nodes. A music node editor might show waves, or knobs. A graphics node editor might show a spinible cube/sphere preview. A node editor for tablets will also likely have a different UX.