Skip to content

Instantly share code, notes, and snippets.

@tonyfast
Created June 28, 2022 18:46
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tonyfast/6c236af7dcaa87fc012f31b720575dd7 to your computer and use it in GitHub Desktop.
Save tonyfast/6c236af7dcaa87fc012f31b720575dd7 to your computer and use it in GitHub Desktop.
Display the source blob
Display the rendered blob
Raw
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@agoose77
Copy link

Yo @tonyfast I missed this meeting and only just stumbled across this.

I'm also interested in the idea of where the notebook format goes - https://discourse.jupyter.org/t/notebook-cell-type-generalisation/10703/8

When looking at the existing schema from the perspective of "I want to completely break your assumptions about Markdown", it quickly feels as though what we have right now is too restrictive.

@tonyfast
Copy link
Author

thanks for the message @agoose77 . i like where you are going with these thoughts. stoked to see folks pushing this topic.

i definitely agree that the notebook is a rich structured document, but i feel that minimizes the polyglot nature. my interpretation is notebooks are "hypermedia collage".

what is funny is we probably agree, but I actually am of the mind that the notebook format is too permissive. my unique experience with pidgy has demonstrated when you elevated markdown to the primary language you naturally lose the ternary of raw, code, markdown cell conventions. instead cells become a binary of ON and OFF cells.

i could see something added to the schema that makes things statement like:

{
  ...
  "if": {
    "cell_type": {"const": "code"}
  },
  "then": {  
     "properties": {"outputs": {"type": "array"}}
  },
  "else": {
     "properties": {"outputs": False}
}
  ...
}

i think y'all might have the best case to make if you can keep the vocabulary near to the existing vocab with minimal changes. the more than can be reused the better. the new json schema approaches are more composable and could allow us to maintain backwards compatibility while evolving the existing schema.

schema vs context

its going to be hard to add a lot of contextual information to a schema. that is not really the goal. schema impose structural consistency, not contextual information. for that tools like json-ld may be a preferred standard for described the context of the markdown in a given document.

further i would suggest looking at the ietf rfcs as there are some recommendations in dealing with markdown variants https://www.rfc-editor.org/rfc/rfc7764.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment