https://discuss.asciidoctor.org/dev-Reorganization-of-the-AsciidoctorJ-AST-data-structures-tp2991p3597.html
My understanding is that the current proposal is as follows:
Node +- BlockNode
| +- Block
| +- Section
| +- Document
| +- List
| +- ListItem
I definitely like the simplicity. I have a few suggestions that could make it more clear.
Inline -> InlineNode
We don't yet have subtypes for Inline, so I think we should mirror the block hierarchy by making the parent type InlineNode. In the future, a more concrete type might be InlineImage or FormattedText...but we don't yet have that mapping.
Node -> ContentNode
I could go either way here, but this could help alleviate the concern that Node is too generic and nondescript. We are working with content, so technically all of the nodes represent content and therefore the name would fit. Let me know what you think.
To pull something from left field, we might want to consider the terminology change that the w3c went through in HTML5, in which they dropped "block" and "inline" in favor of "flow" and "phrasing" since elements could be a little bit of both block and inline. If we followed that changed, we'd end up with:
Node (or ContentNode) +- FlowNode (or FlowContent)
| +- Block
| +- Section
| +- Document
| +- List
| +- ListItem
+- PhrasingNode (or PhrasingContent)
We still have a bit of a funny inheritance from FlowNode (or FlowContent) to Block, but I think it's safe to say that we understand that a Block means "blocks of a section" where blocks hold the actual content.
I'm kind of warming up to the suggested inside the brackets. wdyt?
Cheers,
-Dan