Related to #5
We currently support embedded entities by way of headings or bullet points. It would be useful to be able to enumerate a set of solutions, risks, assumptions, decisions, etc. In the form of a table instead of being forced to use a bulleted list. This would involve extending the current markdown parsing to parse tables and extract from those tables a set of node entries with props based on the the column headings (eg title, status, ...).
We'll need to come up with a good way to determine the node type as that should be expressed once. we might need to try and detect a heading that's annotated with a type as we do already but then detect when there's only a table under that heading, signalling a list of entities of that type (in that case the heading content is otherwise ignored, it's not a title). Heading to know what type the table rows represent
Related to #5
We currently support embedded entities by way of headings or bullet points. It would be useful to be able to enumerate a set of solutions, risks, assumptions, decisions, etc. In the form of a table instead of being forced to use a bulleted list. This would involve extending the current markdown parsing to parse tables and extract from those tables a set of node entries with props based on the the column headings (eg title, status, ...).
We'll need to come up with a good way to determine the node type as that should be expressed once. we might need to try and detect a heading that's annotated with a type as we do already but then detect when there's only a table under that heading, signalling a list of entities of that type (in that case the heading content is otherwise ignored, it's not a title). Heading to know what type the table rows represent