Feature Request: Align `.wlnb` JSON with Jupyter Notebook (`.ipynb`) format for broader compatibility

[divenex]

Hi @njpipeorgan and contributors,

Firstly, thanks for the fantastic wolfram-language-notebook extension! It's a great tool for working with Wolfram Language notebooks within VS Code.

I'd like to propose a feature request to align the underlying JSON structure of the .wlnb files more closely with the standard Jupyter Notebook (.ipynb) format.

Motivation:

Currently, the .wlnb format is already very similar to the Jupyter JSON structure. The primary differences seem to be in key names for cell properties, for example:

• (.wlnb) "languageId" --> "cell_type" (.ipynb)
• (.wlnb) "value" --> "source" (.ipynb)

Additionally, Jupyter notebooks include some global metadata at the end of the file, such as metadata.language_info...

Benefits of Alignment:

1. Enhanced Interoperability: Jupyter is an extremely popular and widely adopted open standard for notebooks. Aligning with its format would significantly enhance the interoperability of notebooks created with this extension.
2. Broader Audience & Sharing: Users could potentially share .wlnb files with colleagues who may not have this specific VS Code extension installed, by simply renaming the file to .ipynb. This would allow viewing (and potentially execution if a Wolfram kernel for Jupyter is present) in any Jupyter-compatible environment.
3. Future-Proofing & Ecosystem: Adhering to a widely used standard like Jupyter's format can help ensure long-term viability and easier integration with the broader data science and computational notebook ecosystem.
4. Simplified Conversion: For users who need to convert between Wolfram Notebooks and Jupyter notebooks, having a nearly identical underlying structure would make the process much more straightforward. The minor differences between my Mathematica converters Mathematica2Jupyter (for .ipynb output) and Mathematica2VSCode (for .wlnb/.vsnb output) already demonstrates how close the formats are, primarily performing key renaming and adding the necessary metadata.

Clarification on Extension Value vs. Standard Jupyter Usage:

It's important to emphasize that this feature request aims to enhance file format compatibility, not to suggest that the extension is merely a wrapper around a standard Jupyter setup.

While one can use the Wolfram Language with Jupyter Notebooks in VS Code directly (e.g., via the Wolfram Language for Jupyter environment), the wolfram-language-notebook VS Code extension provides a distinct and, in many ways, richer experience. This is primarily because the extension leverages VS Code's native Notebook API.

This native API integration means:

• The notebook interface is rendered and managed directly within VS Code, providing a consistent look and feel with other VS Code features.
• The extension can interact more directly with the Wolfram kernel as a "notebook controller" within the VS Code architecture, potentially offering deeper integrations with VS Code's editing, debugging, and language service capabilities.
• It does not require a separate Jupyter Notebook server installation to function; the notebook experience is native to VS Code itself.

Aligning the .wlnb file format with Jupyter's .ipynb would combine the benefits of this superior, VS Code-native user experience with the broad file compatibility of the Jupyter standard.

Question:

Was there a specific reason for the current minor deviations from the Jupyter JSON format when the .wlnb format was designed? Understanding the original design considerations might be helpful.

Proposal:

Consider adopting the Jupyter key names (e.g., cell_type, source) and including the standard Jupyter notebook metadata (like metadata.language_info). This would make .wlnb files essentially Jupyter-compatible .ipynb files with a different extension, offering the best of both worlds: a dedicated, feature-rich Wolfram Language notebook experience powered by VS Code's native Notebook API, and broad file format compatibility with the Jupyter ecosystem.

Thank you for considering this suggestion! I believe it would add significant value to an already excellent extension.