-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Negative feature designators aren't future proof. #23
Comments
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. |
OK let's discuss. IMO this is very badly broken in TTML1 and TTML2 and and we should fix it in TTML2, by:
Removing the works for me label and adding bug. |
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. |
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. |
Meeting today: Nigel to come up with concrete example of difficulty doing feature combination. |
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 |
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). |
The Working Group just discussed 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. |
Addressed https://github.com/w3c/ttml2/issues/697#issuecomment-390088403 in w3c/ttml2@b589579. For more details, see w3c/ttml2#815 (comment). |
@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 |
@nigelmegitt ping |
@nigelmegitt what do you want to do on this issue? close or change to PR milestone? |
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. |
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
andleastRestrictive
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.
The text was updated successfully, but these errors were encountered: