Require support for DFXP presentation and transformation profiles (#3… #565
Conversation
skynavga
requested review from
cconcolato,
andreastai,
palemieux and
nigelmegitt
|
Because (1) it must recognize the profile designator, and (2) for avoidance of doubt (in case something about the TTML2 profile superset turns out to contradict the DFXP profile). |
Yes.
Ok. What it would mean for the processor to support contradicting features in the same namespace? If such a contradiction exists, shouldn't it be noted in the feature specification itself? |
|
On Wed, Jan 17, 2018 at 12:08 PM, Pierre-Anthony Lemieux < ***@***.***> wrote:
Because (1) it must recognize the profile designator
Yes.
(in case something about the TTML2 profile superset turns out to
contradict the DFXP profile).
Ok. What it would mean for the processor to support contradicting features
in the same namespace? If such a contradiction exists, shouldn't it be
noted in the feature specification itself?
Yes, if we know them. I am trying to anticipate a contradiction we don't
know yet. In any case, there is no harm in calling out independent support
for the DFXP profiles.
… —
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#565 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb77aSSTFAWTpscQqnx5vFjlDKF7Lks5tLkUggaJpZM4RfELj>
.
|
Weren't we trying to avoid a normative reference to TTML1? |
|
We were, but it is unavoidable given the resolution to mandate support, which means a normative reference. |
|
@skynavga I think it would be easier to assume that DFXP is a subset of TTML2, and avoid a normative reference. Just a suggestion at this point, and I will approve the PR as-is. |
|
When reviewing the matter of TTML1 reference during this process, I had already decided we needed to make the reference normative due the other citations, e.g., in sections 3.3, 5.2.3.1, and 6.2.12. |
…64).
Closes #364.