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.
Currently, containers are a node type, with
kind, which specifies the type of container (e.g. figure, table, etc), and typedchildrencorresponding 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 theContainernode, allowkindto be more flexible, and makechildrensimplyFlowContent. This would then allow authors to add new numberedkindsin their papers without extending the spec, e.g.Lemma 1.