JSON Canvas – Un formato de archivo abierto para datos de lienzo infinito
Un formato abierto basado en JSON para aplicaciones tipo pizarra de “lienzo infinito”, creado por los autores de Obsidian, se presenta como una forma de hacer portátiles entre herramientas las notas visuales y los grafos de nodos. Los comentaristas acogen con gusto la simplicidad y la alineación con la filosofía de Obsidian de “files over app”, pero argumentan que la especificación 1.0 está poco especificada, es prescriptiva en algunos puntos y es demasiado mínima para captar muchas funciones comunes de lienzo o nuevos tipos de nodos. Hay un interés amplio en la idea de un formato base compartido, junto con preocupaciones sobre interoperabilidad, versionado y si el diseño debería haberse coordinado con otras plataformas importantes de lienzo y diagramación.
Recepción general
- Muchos están entusiasmados con tener un formato abierto y simple para lienzos infinitos y elogian a Obsidian por publicarlo.
- Otros sienten que la especificación es demasiado inmadura como para etiquetarse como “1.0” y la ven más como el formato interno de Obsidian que como un verdadero estándar comunitario todavía.
Diseño de la especificación: simplicidad vs completitud
- La especificación es muy pequeña: nodos con tipo/posición/color, aristas con desde/hacia/color/etiqueta, además de unos pocos subtipos de nodo.
- Algunos aprecian este minimalismo “similar a Markdown” como bueno para la adopción, la legibilidad y la extensibilidad.
- Otros sostienen que está poco especificada y es prescriptiva: colores predefinidos, tipos de nodo fijos, semántica poco clara para campos como
file,backgroundStyley las coordenadas.
Interoperabilidad, extensibilidad y gobernanza
- A muchos les gusta el objetivo de intercambio entre aplicaciones de lienzo, pero cuestionan hasta dónde puede llegar eso cuando las apps innovan principalmente en la semántica y el comportamiento de los nodos.
- Sugerencias:
- Especificación central básica más metadatos extensibles (similar a unist o al frontmatter de Markdown).
- Soporte explícito para tipos de nodo personalizados, estilos y embebidos (URIs, tipos MIME, tipos de enlaces más ricos).
- Campo de versión en el nivel superior; convenciones para extensiones.
- Algunos critican lanzar un “formato abierto 1.0” sin colaboración previa con otras herramientas; otros lo ven como un punto de partida razonable que puede evolucionar mediante retroalimentación.
Detalles técnicos y piezas faltantes
- Se pide:
- Bounding box explícito / metadatos para la vista inicial y la incrustación.
- Definición más clara de coordenadas, unidades, comportamiento del zoom y origen.
- Orden de apilamiento definido (más tarde añadido: el orden del array = índice z).
- Hijos de grupo explícitos en lugar de inferirlos por solapamiento geométrico.
- Más estilos (grosor/estilo del trazo, formas, garabatos, transparencia, enrutamiento de aristas).
- Debate sobre arrays frente a mapas para los nodos, campos obligatorios frente a opcionales, y si deberían existir “nodos punto”.
Elección del formato: JSON vs alternativas
- La elección de JSON se ve como buena para herramientas, uso web y la filosofía de archivos de texto; algunos argumentan que SQLite o formatos binarios serían mejores para la integridad y el rendimiento, mientras que otros señalan que la portabilidad, la capacidad de diff y la simplicidad favorecen JSON.
- Comparaciones con SVG, GraphML, Excalidraw, Argdown, HTML y YAML: varios sostienen que reutilizar o mapear estándares existentes sería más sabio; otros dicen que SVG/HTML son demasiado de bajo nivel o complejos para este modelo gráfico semántico.
UX de lienzo infinito
- Sentimientos mixtos: algunos consideran potentes los lienzos infinitos; otros los encuentran abrumadores y poco alineados con sus modelos mentales.
- Las sugerencias incluyen densidad de información a múltiples escalas, lienzos anidados y herramientas que operen sobre subconjuntos/slices del viewport en lugar de documentos completos.