search

curvenote / notebooks-in-publishing

Documents for using notebooks in publishing
https://curvenote.github.io/notebooks-in-publishing/
Creative Commons Attribution 4.0 International
3 stars 1 forks source link

🪆 Do not nest outputs in a section #20

Closed rowanc1 closed 1 year ago

rowanc1 commented 1 year ago

I am proposing here that we do not have a difference between cells with one output and cells with multiple, with no extra nesting. This is closer to the nbformat, and also means we have one less ID to keep track of and make up.

The one downside of this is that you can't refer to the output list specifically. I think this is fine, any application can easily just refer to the cell and have logic to extract the list of outputs (that is an XML query as well).

I also updated the text to not specify how the IDs are generated (@fwkoch this is the opposite of what we talked about), I don't think it is wise to require a pattern in the ID (e.g. ending/starting in -output-0). The ID could be random, or meaningful, or sequential, and that shouldn't matter.

Change from:

<sec id="nb1-cell-3" sec-type="notebook-code">
  <code language="python" language-version="3.11.1" executable="yes" id="nb1-cell-3-code">
    ...
  </code>
  <sec-text id="nb1-cell-3-output" sec-type="notebook-output"> # Remove this!!
    # output-0 isn't a real tag, but when written out this is also a sec of type notebook-output
    <output-0 id="nb1-cell-3-output-0" /> 
    <output-1 id="nb1-cell-3-output-1" />
    <output-2 id="nb1-cell-3-output-2" />
  </sec-text>
</sec-text>

To this:

<sec id="nb1-cell-3" sec-type="notebook-code">
  <code language="python" language-version="3.11.1" executable="yes" id="nb1-cell-3-code">
    ...
  </code>
  <sec id="nb1-cell-3-output-0" sec-type="notebook-output">...</sec>
  <sec id="nb1-cell-3-output-1" sec-type="notebook-output">...</sec>
  <sec id="nb1-cell-3-output-2" sec-type="notebook-output">...</sec>
</sec>

(The heart of the code change is in #19...)

fwkoch commented 1 year ago

I agree that we shouldn't be prescriptive about what the IDs look like for the sequential outputs, etc. - Really, they are probably not even mandatory if they are never referenced anywhere...?

That feels like a client-side concern (i.e. myst-to-jats can still generate output ids like we talked about).

rowanc1 commented 1 year ago

Talked about in #23, and all agreed that we get this in!