Closed skynavga closed 4 years ago
@palemieux
In what way does replacing instances of specific language with a general rule constitute a "significant change"?
In what way does this remove an important clarification?
Moving this PR (and related Issue) to 3ED, as this is clearly going to become another philosophical debate about editorial style, and only serve to delay 2ED publishing schedule.
I agree with @palemieux here - it is clearer to state that the steps need to be executed in the specified order every time that is the case than to state exceptions where it is not the case.
@nigelmegitt that's letting the cart drive the horse; i'm not sure there are any exceptions to the rule
i'm not sure there are any exceptions to the rule
@skynavga that "I'm not sure" is the strongest argument yet for retaining the qualification locally to each list. If you as the editor are not sure if there are any exceptions, I reckon it's likely that most other readers will not be sure in the opposite direction, i.e. they will be unclear if the list of steps must be executed in the specified order or in any order.
@nigelmegitt if there is an exception (and I very much doubt it), then you can darn well be sure there is very explicit language pointing out that exception; but I would say the burden of proof is on someone who presumes there is an exception to the rule that would require us to explicitly state in each instance that rules are ordered (as opposed to stating that it is always the case for numbered steps/rules);
I should also note that the underlying semantic markup is olist
vs ulist
, which makes it explicit, so I never would have used olist
if I intended the list to be unordered.
I thought about the difference between olist
and ulist
and realised that even with steps that can be executed in any order we would still need to use olist
in the specification, otherwise we would find it difficult to refer to individual steps. I don't know if there is a good semantic match in HTML for a list that has unique numbers for referencing but whose members are not sorted.
My preference here remains not to make the change.
At present the spec is inconsistent because we have inadvertently added explicit language about ordering in some but not all places where we should have not done so and stated a general rule or should have done so everywhere. It is redundant to fix this by taking the latter approach IMO when the former is safer (since we would not need to worry about forgetting to add explicit language in every new ordered list in the future as the general convention would cover it).
some but not all places
which places have a list of steps but don't say if they must be executed in order?
olist
enumerates a list of criteria with no implied ordering, so ulist
would also workolist
enumerates a list of criteria with no implied ordering, so ulist
would also workolist
enumerates a list of criteria with no implied ordering, so ulist
would also workolist
enumerates a list of criteria with no implied ordering, so ulist
would also workolist
enumerates a list of criteria with no implied ordering, so ulist
would also workolist
doesn't state "in order" but prose uses "after" and "then" to make order explicitulist
to indicate the use of unordered rules/steps (so do not mistakenly use ordered lists exceptionally marked as ordered by prose);ttp:profile
in two instancesttp:feature
in one instance (2nd bullet of 3 bullet ulist
)ttp:extension
in one instance (2nd bullet of 3 bullet ulist
)image
two element olist
should be changed to bulleted ulist
as no order is impliedtts:direction
explicitly states exceptionally "the following ordered rules, where the first applicable rule applies"tts:extent
olist
should be ulist
since no order is impliedolist
is missing "in order"olist
is missing "in order"olist
is missing "in order"tts:lineHeight
olist
missing "in order"tts:showBackground
olist
missing "in order"tta:speak
olist
missing "in order"olist
should be ulist
since no order is impliedolist
missing "in order"olist
missing "in order"olist
missing "in order"olist
missing "in order"olist
missing "in order"animate
olist
should be ulist
since no order is impliedset
olist
should be ulist
since no order is impliedanimate
olist
missing "in order"olist
missing "in order"olist
missing "in order"olist
missing "in order"olist
missing "in order"olist
missing "in order"Thank you for the analysis @skynavga . Given https://github.com/w3c/ttml2/pull/1179#issuecomment-542314468 I currently believe the best solution to this would be:
olist
throughout so that steps may be explicitly referenced, AND:Point 2 above could be simplified perhaps by defining terms for:
and using the applicable term as a shortcut for describing the list of steps with fewer words. We'd end up with language like "Execute the following any-order steps:".
@nigelmegitt I don't follow you. In none of the cases in my analysis is it the case that numbered items can be evaluated in any order other than the numbered order. In particular, in none of the cases does the text admit evaluation in any order.
To be very clear, numbered lists are always performed in the numbered order whenever they represent rules/steps/etc (as opposed to criteria/cases). The only distinction is whether (1) evaluation stops when the first rule/step is successfully evaluated or (2) evaluation conditions to the last numbered item regardless of whether a rule/step is successfully evaluated. The latter being the default, and the former being the exceptional case and explicitly marked in the text.
In none of the cases in my analysis is it the case that numbered items can be evaluated in any order
I am proposing that the fact that items are numbered should not be taken to imply that the steps are ordered. Numbering does two things: 1. it suggests some position within an order that may or may not be important for processing, 2. it facilitates external reference of the step, so we can say "step 3 does that job" or "there's a problem with step 5".
In your analysis @skynavga you include, for example:
- §13.1.3
set
olist
should beulist
since no order is implied
If we do this, then we will no longer have an easy way to refer to the steps. However this would then mean that we need to be explicit in the text that no order is implied.
Hope that helps explain my thinking?
I am proposing that the fact that items are numbered should not be taken to imply that the steps are ordered.
And I am saying that in all cases where numbered lists state rules or steps (of a procedural nature), then they are intended to be ordered (whether so stated or not).
In your analysis @skynavga you include, for example:
§13.1.3 set olist should be ulist since no order is implied
If we do this, then we will no longer have an easy way to refer to the steps. However this would then mean that we need to be explicit in the text that no order is implied.
And in all of these cases (where olist
was used when ulist
should have been used), the items are not rules or steps (of a procedure) but are (unordered) criteria or constraints.
The correct (and logical) response is to change these latter to ulist
, to add a general convention for numbered lists of rules/steps, and to remove references to "in the specified/indicated order (etc)".
the items are not rules or steps (of a procedure) but are (unordered) criteria or constraints.
Regardless of this, it is still useful to be able to reference those criteria or constraints.
The Timed Text Working Group just discussed Improve anonymous span prose, generalize ordered rule convention (#1139). ttml2#1179
, and agreed to the following:
SUMMARY: @skynavga to add ordering language to deal with original scope of issue, and raise new issue for general ordering of steps, targeted at 3rd Ed.
@palemieux I believe the above commits should address your comments. Let me know if otherwise.
The Timed Text Working Group just discussed Improve anonymous span prose, clarify rule ordering (#1139). ttml2#1179
.
@skynavga In the case of p
, why wouldn't a child text node not always result in an anonymous span?
@palemieux I give up. I removed the text under p
as well.
Closes #1139.
Implement https://github.com/w3c/ttml2/issues/1139#issuecomment-526928441 modulo the following: