search

w3c / ttml3

Timed Text Markup Language 3 (TTML3)
http://w3c.github.io/ttml3/
Other
6 stars 6 forks source link

Negative feature designators aren't future proof. #23

Open nigelmegitt opened 6 years ago

nigelmegitt commented 6 years ago

The way that non-support inverse style feature designators like #textEmphasis-no-color and #textEmphasis-no-quoted-string are defined is open ended. Rather than requiring support for a specific subset of syntax+semantics, they require for support for everything except some syntax+semantic, in an open ended way.

This means that if in the future an additional syntax+semantic is added to the value set of tts:textEmphasis, then the meaning of those features would change by default.

It also presents a bit of a logic puzzle, to say the least, when interpreting mostRestrictive and leastRestrictive with respect to negative features.

To avoid this, I propose we refactor those features so that we only have positive definitions, i.e. support for a bounded set of syntax and semantics.

skynavga commented 6 years ago

We already have "negative" definitions of features in TTML1, e.g., #textOutline-unblurred, so we can't back out that history. I suggest you propose clarifications to specific features in TTML2, but only if necessary at this point.

Labeling as works for me and agenda.

nigelmegitt commented 6 years ago

OK let's discuss. IMO this is very badly broken in TTML1 and TTML2 and and we should fix it in TTML2, by:

  1. deprecating negatively expressed feature designators inherited from TTML1.
  2. adding new positively expressed feature designators into TTML2.
  3. specifying that new feature or extension designators should be positively expressed.

Removing the works for me label and adding bug.

skynavga commented 6 years ago

I do not agree with your assessment (that there is a bug and that it needs a change now). Let's wait until we can discuss.

skynavga commented 6 years ago

The only way I can see addressing this is to go through every feature in TTML1 that is marked as first defined by Version 1 (TTML1) and add a qualifier of the form "as defined or equivalent to the definition specified by [TTML1]". Doing so, we could still add "notwithstanding" notes warning the reader about exclusions, but those notes wouldn't be part of the normative definition of the feature.

The alternative you suggest (create a whitelist for every feature) would be very time consuming and prone to error, particularly since it would involve repeating the formal definition of the syntax or semantics found in the body of the specs, a task we certainly cannot under take.

nigelmegitt commented 6 years ago

Meeting today: Nigel to come up with concrete example of difficulty doing feature combination.

nigelmegitt commented 6 years ago

This issue was discussed by the working group today, and minuted at https://www.w3.org/2018/05/17-tt-minutes.html#item11

RESOLUTION: Mark TTML1 features as relating to the TTML1 definition

SUMMARY: This resolution is logged as #763

skynavga commented 6 years ago

In order to reduce the likelihood of dealing with this, I will break out the semantics of profile combination into separate features (as an additional update to PR #747 (issue #687).

css-meeting-bot commented 6 years ago

The Working Group just discussed Negative feature designators aren't future proof. ttml2#697.

The full IRC log of that discussion <nigel> Topic: Negative feature designators aren't future proof. ttml2#697
<nigel> github: https://github.com/w3c/ttml2/issues/697
<nigel> Nigel: I still have the action on this.
<nigel> Glenn: To some extent #794 overtakes this because we are already backing out some
<nigel> .. negative feature designations. I'm not sure if there are potential action items.
<nigel> Nigel: Let me keep it and think further on this please.
<nigel> .. The action on me is to demonstrate that there is a specific problem.
<nigel> Glenn: The only remark I have is that one of the reasons we use the phrase "all defined values"
<nigel> .. is that not all values are enumerable, e.g. floating point values, and the primary condition
<nigel> .. expressions are infinite in their number of possibilities, so we can't enumerate every
<nigel> .. value set.
<nigel> Nigel: There are ways to group value sets finitely.
<nigel> Glenn: In the condition refactoring, where you suggested using "non-function" expressions,
<nigel> .. there probably isn't any other way to do it.
<nigel> Nigel: Ok the action is still with me.
<nigel> Glenn: My point is even if you think we'd like to do this I don't think we can completely
<nigel> .. do what you're suggesting, in the case of some infinite value sets.
skynavga commented 6 years ago

Addressed https://github.com/w3c/ttml2/issues/697#issuecomment-390088403 in https://github.com/w3c/ttml2/commit/b589579ef1a6e07cec0b0fdaf8d796f8edc49af7. For more details, see https://github.com/w3c/ttml2/pull/815#issuecomment-395947519.

skynavga commented 6 years ago

@nigelmegitt given https://github.com/w3c/ttml2/issues/697#issuecomment-395946322, I recommend this issue be closed and marked for possible re-consideration in ttml.next

skynavga commented 6 years ago

@nigelmegitt ping

skynavga commented 6 years ago

@nigelmegitt what do you want to do on this issue? close or change to PR milestone?

nigelmegitt commented 6 years ago

I still intend to look at the logic issue, but in the meantime, we aren't going to refactor the TTML1 features that have the characteristic raised in this issue, and have made good progress in avoiding introducing new ones in TTML2. Closing this and marking for ttml.next. If/when I get to dig into the logic problem, and if I find there is indeed an issue, I'll reopen or open a new issue.