You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, containers are a node type, with kind, which specifies the type of container (e.g. figure, table, etc), and typed children corresponding to the kind (e.g. figure -> image + figure caption).
This doesn't follow the pattern of other nodes: we shouldn't need to look at kind to resolve/validate the children. If we want to be strict about children, each container should probably be its own node type, e.g. ContainerFigure. However, if we want it to be easy to add new kinds, we could keep the Container node, allow kind to be more flexible, and make children simply FlowContent. This would then allow authors to add new numbered kinds in their papers without extending the spec, e.g. Lemma 1.
The text was updated successfully, but these errors were encountered:
Currently, containers are a node type, with
kind
, which specifies the type of container (e.g. figure, table, etc), and typedchildren
corresponding to the kind (e.g. figure -> image + figure caption).This doesn't follow the pattern of other nodes: we shouldn't need to look at kind to resolve/validate the children. If we want to be strict about
children
, each container should probably be its own node type, e.g.ContainerFigure
. However, if we want it to be easy to add new kinds, we could keep theContainer
node, allowkind
to be more flexible, and makechildren
simplyFlowContent
. This would then allow authors to add new numberedkinds
in their papers without extending the spec, e.g.Lemma 1
.The text was updated successfully, but these errors were encountered: