JSON Canvas – 一种用于无限画布数据的开放文件格式

总体反响

• 许多人对拥有一种开放、简单的无限画布格式感到振奋，并赞赏 Obsidian 发布了它。
• 也有人觉得该规范过于不成熟，不应被标为“1.0”，更像是 Obsidian 的内部格式，而不是一个真正的社区标准。

规范设计：简洁性 vs 完整性

• 该规范非常小：包含带有类型/位置/颜色的节点，带有 from/to/颜色/标签的边，以及少数几种节点子类型。
• 一些人欣赏这种“类似 Markdown”的极简主义，认为它有利于采用、可读性和可扩展性。
• 另一些人则认为它定义过少且带有主观倾向：预设颜色、固定节点类型、以及诸如 file、backgroundStyle 和坐标等字段的语义不清。

互操作性、可扩展性与治理

• 许多人喜欢在不同画布应用之间交换的目标，但质疑当应用主要在节点语义和行为上创新时，这能走多远。
• 建议包括：
  • 基线核心规范加可扩展元数据（类似 unist 或 Markdown frontmatter）。
  • 明确支持自定义节点类型、样式和嵌入（URI、MIME 类型、更丰富的链接类型）。
  • 在顶层加入版本字段；为扩展制定约定。
• 有人批评在没有与其他工具事先协作的情况下就推出“1.0 开放格式”；也有人认为这是一个合理的起点，可以通过反馈不断演进。

技术细节与缺失部分

• 有人呼吁：
  • 明确的边界框 / 初始视图和嵌入所需的元数据。
  • 更清晰地定义坐标、单位、缩放行为和原点。
  • 定义 z 排序（后续已加入：数组顺序 = z-index）。
  • 明确的组子元素，而不是通过几何重叠来推断。
  • 更多样式支持（描边宽度/样式、形状、涂鸦、透明度、边的路由）。
• 关于使用数组还是映射来表示节点、必需字段与可选字段，以及是否应存在“点节点”的争论也很激烈。

格式选择：JSON vs 其他方案

• 选择 JSON 被认为有利于工具链、Web 使用以及“文本文件优先”的理念；也有人认为 SQLite 或二进制格式在完整性和性能上更好，而另一些人则指出可移植性、可 diff 性和简洁性使 JSON 更有优势。
• 与 SVG、GraphML、Excalidraw、Argdown、HTML 和 YAML 的比较：一些人认为重用或映射到现有标准可能更明智；另一些人则认为 SVG/HTML 对这种语义化、图状模型来说过于底层或复杂。

无限画布 UX

• 感受不一：一些人觉得无限画布很强大；另一些人则觉得它令人不知所措，并且与他们的心智模型并不契合。
• 建议包括多尺度信息密度、嵌套画布，以及在子集/视口切片上而不是整个文档上运行的工具。