Wow—21 posts already! The bike shed effect seems to be in full flight … [And yes, I know I have my share in this ]
@chrisalley: I’m a bit confused by you stating whatever is decided should reflect the output more than the input and then going on to—correctly and instructively—pointing out that the output rendering is completely out of the author’s hands. So I assume that should reflect the output does in fact mean the parsing result (aka AST, aka CommonMark DTD element structure).
With which I agree completely, and would thus prefer names which allude to the “two kinds of list” usually found in target document types like HTML, DocBook, “general document”, LATEX and so forth. So far I have only seen these alternative names in common use:
- “unordered” and “ordered”: In the ISO 8879 “general document” and HTML DTDs;
“itemized” and “ordered”: In DocBook;
- “itemized” and “enumerated”: In LATEX.
In addition, one might take the following “prior art” into account; but I don’t make any claim of completeness for this collection of references.
In contrast to using two (or more) element types for various kinds of lists, the ANSI/NISO Journal Article Tag Set and the (related) ISO Standards Tag Set (ISOSTS) both conflate the two kinds of list into a single element type,
<list>, and distinguish them using an attribute
list-type with predefined values like
"alpha-lower", or “
bullet” (sic!). The explanation for “
bullet” however reads:
Unordered or bulleted list. Prefix character is a bullet, dash, or other symbol.
So there: “unordered” again.
And just for completeness: The ISO 12083 Electronic manuscript preparation and markup DTD seems to use the same approach when it comes to lists, but simply employs numbers to indicate the “list type”, together with vague “suggestions” (but note the word “bullet” here again!):
<!-- l.types = Suggestions for list types:
1=arabic, 2=upper alpha, 3=roman, 4=bullet, 5=dash,
6=unlabelled; if more needed (e.g. lower alpha)
modify or extend this list as necessary. -->
<!ENTITY % l.types "(1 | 2 | 3 | 4 | 5 | 6) #IMPLIED" >
[ Although the ATTLIST declaration for the
<list> element type does not declare the
type attribute using NUMBER as the declared value, but references the above parameter entity as a name token group. ]
And another one, this time from ISO/IEC 26300-1:2015, aka OASIS OpenDocument: there’s only one element type for list, unsurprisingly named
<text:list> (this is XML!). Pretty much all rendering properties of such a list seem to be specified in an associated “list style”:
Lists may be numbered. The numbering may be restarted with a specific numbering at each list item. Lists may also continue numbering from other lists in order to merge lists into a single, discontinuous list. Whether list numbering is displayed or not depends on the list style being used. [ISO 26300-1:2015, clause 5.3.1]
This “list style” is determined by the attribute
<text:list>, which may be missing. In this case, clause 5.3.2 gives the following advice:
If a list does not have a
style:name attribute and therefore no list style is specified, one of the following actions is taken:
If the list is contained in another list, the list style defaults to the style of the surrounding list.
If there is no list style specified for the surrounding list, but the list contains paragraphs that have paragraph styles attached that specify a list style, that list style is used.
An implementation-dependent default is applied to the list.
To determine which formatting properties are applied to a list, the list level and its style name are taken into account. 16.30.
The “16.30” above refers to clause "16.30
<text:list-style>", which explains what kind of “style elements” the
<text:list-style> element may contain for each “list level”. — I’m too lazy to go into that. (Let alone to dig into Microsoft’s “Office Open XML” stuff …)
To conclude: it really is a mess, and it really does not matter much
But if one useful thing can be gleamed from these examples, it probably is the approach to use only one element type for lists, and to “customize” all list properties using attributes; and it seems that newer document types tend to go into this direction. Note that this is also the approach taken in the CommonMark DTD, which has a single
<list> element type.