Add note clarifying definition of [content element] (#276). #586
Conversation
There was a problem hiding this comment.
This is okay as is but insufficient. I would prefer the bullet list in §8.1 adjusted to make it clear that only a subset of the elements in the section (8.1) titled "Content Element Vocabulary" are in fact in the content element vocabulary class. For example by splitting 8.1 into 8.1 and 8.2, keeping the tt and head element definitions in 8.1, renamed to "Document and head element vocabulary" and moving the content element vocabulary items to 8.2, which would be called "Content element vocabulary".
|
@nigelmegitt I disagree. Doing that would make all other vocabulary sections inconsistent. One note is sufficient. |
|
@skynavga that only serves to point out that the inconsistency goes further. It does indeed look like the core catalog's element vocabulary and element vocabulary groups use very similar labels to the specification headings as visible in the table of contents, not to mention defined terms such as [content element]. So we have three grouping mechanisms within the specification that assign different groups of elements to the same labels. If you don't want to restructure the whole specification, which I can understand, then we at least need to add some kind of note or structure change to §5.3.1 to explain it. The note on [content element] does not look like enough. |
|
@nigelmegitt there is no inconsistency; formal uses of "content element" that point to "[content element]" are defined by the latter; the enumeration in 8.1 has no formal role in that respect; it is merely an introduction to the section that enumerates the subsections, as it the case elsewhere; at most, I can add a note to this effect in 8.1, but I am not subdividing 8.1, otherwise, someone will think that 8.1 plays a formal role in defining a named set of elements, which it does not do |
There was a problem hiding this comment.
There is something inconsistent here. Section 8.1 is Content Element Vocabulary. Table 5-3 is the Element Vocabulary with a Content row. The two do not match.
What about simply expanding the definition of [content element] to include all Content Element Vocabulary? [content element] seems to be qualified in the prose, e.g. "some content elements", and the style definitions, style resolution process, timing model, layout semantics, and content model ultimately constrains what applies to each of the elements in the Content Element Vocabulary.
|
There is nothing inconsistent here. The definition found in "[content element]" is unambiguous. The fact that the formal term "[content element]" and the heading "Content Element Vocabulary" both contain the words "content" and "element" produces neither an ambiguity nor an inconsistency. They are distinct. Furthermore, the presence of The only thing I am willing to do further in resolving this issue is to add a Note at the end of the enumerated list of sub-section headings in 8.1 that reminds the reader (one more time) that this list is not equal to the list of elements defined by "[content element]", and this is intended (and not accidental). |
@skynavga In the formal sense you may be right, but readability is important to specs too, and using essentially the same labels in different contexts to mean different things is bad for readability and does appear inconsistent, which is something we can ill afford given its complexity. We should be doing everything we can to make it easier for people coming to the spec to pick it up.
That would go some way to helping. For completeness, again, something similar in §5.3.1 is also needed. |
|
@nigelmegitt This has been in TTML1 since its 1st Edition, and, to my knowledge, has never produced a single question from an implementer or author. IMO folks are seeing problems that don't exist here. I added the note under "[content element]" which is already enough new clutter to address a non-problem. |
|
@skynavga In "E.1.145 #region-inline-explicit", what does "content element vocabulary" refer to? |
|
@nigelmegitt thanks for pointing out those typos, which I have just now fixed |
|
@skynavga I think the credit goes to @palemieux ! |
|
@skynavga This definitely clears up ambiguities. There is a couple of more errand "TTML content element" that should probably be "content elements". So it looks like the heading "Content Element Vocabulary" is intended to be interpreted as "Element Vocabulary of Content Matters". Is that right? |
|
@palemieux I will check these uses and modify as needed; the phrase "Content Element Vocabulary" is simply the title of Section 8.1 and serves no other purpose. It also appears in the phrase "Embedded Content Element Vocabulary", the title of Section 9.1. |
Ok. Since Section 8.1 is a child of Section 8, whose title is "Content", couldn't the title of Section 8.1 simply be "Element Vocabulary"? This would remove any ambiguity. This a akin to class properties not repeating the classe's name. |
|
No, since that would break naming symmetry elsewhere. One more time, there is no ambiguity. I don't know how many times I need to say this. |
@skynavga I don't know either - does repetition make the assertion more correct? ;-) |
|
@palemieux fixed the reference to "TTML content elements" |
|
@skynavga Links to definition are missing from other feature definitions, e.g. |
|
@palemieux added all appropriate links to content element |
Closes #276.