Potential semantic conflict between ttp:profile and ttp:contentProfiles.

[skynavga]

At present, neither IMSC1.2 nor TTML2 says anything about the case where a document requires a processor to support one profile but declares the document to conform to another profile that is mutually exclusive with the former. Since TTML2 doesn't define mutually exclusive profiles, TTML2 has not had the need to say anything of note in this regard, but it would possibly seem relevant for IMSC1.2 to do so given the mutual exclusivity of its text and image profiles. For example, it would be a bit strange for a document to specify

<tt
  xmlns="http://www.w3.org/ns/ttml"
  xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
  ttp:profile="http://www.w3.org/ns/ttml/profile/imsc1.1/text"
  ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/image">
...
</tt>

However, AFAICT, this is a perfectly legitimate IMSC1.X document.

[nigelmegitt]

I am not so sure this isn't a TTML2 issue. If TTML2's [construct effective processor profile] and [construct effective processor profile] algorithms can not resolve a profile unambiguously given a strangely formed document like this then that is potentially a bug in those algorithms.

In this specific case of the Text and Image profiles, we can enumerate the possibilities of what a processor might do, assuming that either option might be chosen by any processor:

Profile chosen by implementation	Actual document profile	Result
Text	Text	OK
Text	Image	Not valid, presumably no presentation
Image	Image	OK
Image	Text	Not valid, presumably no presentation

Ultimately in the not ok cases it does seem to be a fault in the document that needs to be resolved.

[skynavga]

Clearly, a processor cannot resolve this problem, so it cannot be a TTML2 issue. That is, TTML2 semantics are perfectly clear. In the Not OK cases above, if validation were not enabled, then presentation need not occur depending upon whether the processor implemented the features used from the actual document profile.

What I was thinking, however, was that IMSC, which does place many restrictions/constraints on documents, might wish to prohibit a document from specifying the Not OK cases above, which could be checked by a validator to avoid inconsistent usage.

[palemieux]

That is, TTML2 semantics are perfectly clear.

@skynavga What are the semantics?

[palemieux]

Given the example at https://github.com/w3c/imsc/issues/506#issue-513893582, the effective processor profile will be http://www.w3.org/ns/ttml/profile/imsc1.1/image, and the effective content profile will be http://www.w3.org/ns/ttml/profile/imsc1.1/text.

As a result:

• the processor is only required to support those features supported by the Image Profile; and
• the document must conform to the Text Profile, which means it must not contain features that are prohibited in the Text Profile.

So, unless the document is empty, the resulting presentation may be incomplete.

It might be smart for a validator to highlight this fact, i.e. that the intersection of the effective processor profile and effective content profiles is the null set, but I do not see a requirement to prohibit it in IMSC.

[skynavga]

ok, but IMSC has plenty of requirements that can be paraphrased as "don't do stupid <fill in the blank>"

[palemieux]

IMSC does not constrain the effective processor profile and effective content profile to be the Image Profile or the Text Profile, so prohibiting the effective processor profile to be the Image Profile if the effective content profile is equal to the Text Profile -- or vice versa -- would catch only corner cases, right?

[skynavga]

Yes, this is certainly a corner case, so it is a judgment call as to whether too spec it, or let the author get what they asked for. I don't have a strong opinion, and am fine with letting the existing semantics hand the author what they've asked for.

[palemieux]

I don't have a strong opinion, and am fine with letting the existing semantics hand the author what they've asked for.

As I recall, we used to have all kinds of complicated logic, and ultimately chose to (a) specify constraints on documents, (b) mandate features supported by processors and (c) to let the (unambiguous) TTML2 profile resolution algorithm tell the author whether they are doing something silly and/or inform processors of potential issues.

[nigelmegitt]

@skynavga we'd like to be able to resolve this before or during Thursday's call if possible.

[skynavga]

@nigelmegitt my input is above

[css-meeting-bot]

The Timed Text Working Group just discussed Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506, and agreed to the following:

• SUMMARY: proposal listed above to add a normative SHOULD statement to TTML2, left open for further consideration before resolving.

The full IRC log of that discussion

<nigel> Topic: Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506
<nigel> github: https://github.com/w3c/imsc/issues/506
<nigel> Pierre: I think this is literally not an issue.
<nigel> .. I think it is not impossible to fulfil the IMSC document at the top of the issue with an empty document.
<nigel> .. It's a silly document but not impossible.
<nigel> Cyril: When we have this situation with non-overlapping profiles, what should a validation processor do?
<nigel> Pierre: TTML2 is very clear. Theoretically the validator knows about all the profiles being flagged.
<nigel> .. For instance processor profile is Image and document conformance is Text. A validator should flag the document
<nigel> .. as non conformant unless it is empty.
<nigel> Cyril: but how? It will validate against the rules for Image or for Text and some might fail?
<nigel> Pierre: The processor profile lists features the processor must support.
<nigel> .. In the thread there's a specific example.
<nigel> .. The processor profile is Image and the content profile is Text.
<nigel> .. That means the processor is only required to support those features supported by Image profile but the document
<nigel> .. must conform to Text profile.
<nigel> .. Let's say the document conforms to Text profile and is not empty, it contains some spans that are forbidden in Image Profile.
<nigel> .. A smart validator would recognise that, and see that a processor has no chance of processing that document
<nigel> .. accurately.
<nigel> .. It should flag it.
<nigel> Andreas: But the document would still be conformant.
<nigel> .. The validator might warn but from the spec side it is not forbidden.
<nigel> Pierre: That's correct.
<nigel> Nigel: We should separate the two questions of a validator:
<nigel> .. 1. Is the document conformant to its declared content profile? (in this case, yes)
<nigel> .. 2. Would a processor that meets the requirements of the effective processor profile as computed from the document
<nigel> .. be able to process it successfully?
<nigel> .. The two questions are distinct.
<nigel> Pierre: Andreas pointed out that from a validation standpoint the document would validate correctly because it does
<nigel> .. conform to Text profile. A smart validator might point out that the processor profile is only a subset and therefore
<nigel> .. it is unlikely that the document would be correctly rendered.
<nigel> .. That's my understanding of profiles in TTML2.
<nigel> Cyril: It could also say the document is not valid for the processor profile.
<nigel> Pierre: In TTML2 the way it is stated is if a feature is in a processor profile then the processor must support it but
<nigel> .. it does not say that the processor must not support other featuers.
<nigel> s/uer/ure
<nigel> .. So the best thing a validator could say is a warning that on the requested type of processor the document might
<nigel> .. not present the document correctly.
<nigel> Cyril: There's already a recommendation in the spec to use contentProfiles signalling unless backward compatibility
<nigel> .. with TTML1 is needed.
<nigel> Pierre: [checks what it says]
<nigel> .. It already says either use Image or Text but not both. The only reasonable way to do both is an empty document.
<nigel> .. But yes IMSC says contentProfiles _should_ be present.
<nigel> Cyril: We want to catch as much as possible at validation. I wonder how we can improve...
<nigel> Pierre: It's a TTML2 issue that a TTML2 validator should flag this kind of stuff.
<nigel> Nigel: We could say that if processor profiles is present and says one of Image or Text but not both and says
<nigel> .. the opposite of contentProfiles then that should generate a warning.
<nigel> Pierre: We designed IMSC to be a superset of profiles like EBU-TT-D so I don't know how we'd write that.
<nigel> Nigel: We would have to express it in terms of the computed set of features supported by the processor and enabled
<nigel> .. by the content profile. The set of features that may be present in the document should all be in the set of features
<nigel> .. supported by the processor, or generate a warning.
<nigel> Pierre: That should be in the generic TTML2 validation processing not in IMSC though.
<nigel> .. Exactly what you suggested Nigel would be a good TTML2 addition. That's useful everywhere really.
<nigel> Nigel: I can raise that as an issue then.
<nigel> Pierre: One thing we could do is put that as a proposed resolution and move the issue into TTML2 instead of opening
<nigel> .. a new issue.
<nigel> .. See if Glenn has a reason why this is not a good idea.
<nigel> Proposal: Add a normative SHOULD statement to TTML2: The set of features that may be present in the document should all be in the set of features supported by the processor, or generate a warning.
<nigel> Nigel: I suggest we don't resolve this now but leave it open for Glenn to respond.
<nigel> Pierre: That would be my preferences.
<nigel> s/ces/ce
<nigel> SUMMARY: proposal listed above to add a normative SHOULD statement to TTML2, left open for further consideration before resolving.
<nigel> Pierre: I'm reading what "validate a document" does and it does not do that at all at the moment today.
<nigel> .. I don't think this is covered in TTML2 today.

[css-meeting-bot]

The Timed Text Working Group just discussed Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506, and agreed to the following:

• SUMMARY: @skynavga to consider the proposal further

The full IRC log of that discussion

<nigel> Topic: Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506
<nigel> github: https://github.com/w3c/imsc/issues/506
<nigel> Nigel: The proposal from last week was:
<nigel> .. Add a normative SHOULD statement to TTML2: The set of features that may be present in the document should all be in the set of features supported by the processor, or generate a warning.
<nigel> .. This is a proposed requirement for a validator, based on mismatches between the effective content profile and the
<nigel> .. effective processor profile.
<nigel> .. If we agree to this proposal then we will move the issue to the TTML2 repo.
<nigel> Glenn: It's semantically inconsistent with the definition of processor profiles because only features that the processor
<nigel> .. profile designates to be required elicits an abort... [thinking out loud]
<nigel> .. It might never produce a warning. I need to think about it a little more.
<nigel> .. Offhand that doesn't sound semantically consistent with the current semantics but I'll give it a once-over offline.
<nigel> Nigel: Thank you
<nigel> SUMMARY: @skynavga to consider the proposal further

[css-meeting-bot]

The Timed Text Working Group just discussed Potential semantic conflict between ttp:profile and ttp:contentProfiles. w3c/imsc#506.

The full IRC log of that discussion

<nigel> Topic: Potential semantic conflict between ttp:profile and ttp:contentProfiles. w3c/imsc#506
<nigel> github: https://github.com/w3c/imsc/issues/506
<nigel> Nigel: Where we left this last time was Glenn was going to have a think about this some more.
<nigel> Glenn: I'm afraid I haven't been able to do that.

[skynavga]

I have reviewed the proposal made by Nigel in https://github.com/w3c/imsc/issues/506#issuecomment-565085770 and have concluded that this proposal is overreaching, and will be a far greater burden on implementers than might ever be derived as a benefit for authors. Furthermore, upon reviewing the original issue and the underlying TTML2 semantics, I have determined that there is no essential semantic conflict, which is to say, if an author defines and declares a document to adhere to some content profile A and then subsequently requests that the document be processed using a processor profile B that is incompatible with content profile A, then it is the author's prerogative to do so, however unwise that might be. In particular, it does not seem necessary to standardize any semantics for this scenario in the specification at this time, and, therefore, I propose to close this issue without any further action.

[skynavga]

In a future edition of TTML2, e.g., 3rd Edition, I would suggest an informative note something along the lines of the following. This would permit implementation experience to be gained and QOI (quality of implementation) competition to occur in the area of validation/verification functionality in the content constraint specification, a matter that should proceed with caution in the base standard.

Note: Content authors may wish to make use of TTML content verification tools that detect and warn about overly constrained uses of content and processor profile attribute vocabulary; for example, were a content author to specify that a document adheres to a content profile X, but then specify that an processor profile Y be used to process the document where profiles X and Y are semantically incompatible.

[css-meeting-bot]

The Timed Text Working Group just discussed Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506, and agreed to the following:

• SUMMARY: Consensus reached to add a note to IMSC 1.2 along the lines of @skynavga's comment earlier today. Comments from the Editor welcome.

The full IRC log of that discussion

<nigel> Topic: Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506
<nigel> github: https://github.com/w3c/imsc/issues/506
<nigel> Nigel: I see that Glenn has given this some thought and added some comments.
<nigel> .. This includes a proposal for an informative note for TTML2. That could go into IMSC too.
<nigel> Glenn: Sure, I wouldn't mind that in IMSC 1.2, that'd be fine.
<nigel> Nigel: I certainly wouldn't object to that.
<nigel> Glenn: There's another note with similar language at the beginning, under styles.
<nigel> Nigel: I see, in the note at the bottom of https://www.w3.org/TR/ttml2/#styling-attribute-vocabulary
<nigel> Glenn: I have 10-12 issues on TTV asking for warnings that aren't in any specification that a tool could do,
<nigel> .. for example every IDE or tool chain has something like lint or the equivalent that suggests things that an author
<nigel> .. might want to avoid, and it's always something that gets developed and enhanced over time. There's no standard
<nigel> .. for them, and they get improved. I consider it a Quality of Implementation and competition issue.
<nigel> .. Standards can never adequately enforce everything that implementers might come up with.
<nigel> Cyril: Maybe having the warning in the IMSC specification would prevent IMSC authors from doing stupid things.
<nigel> .. I'm wondering in practice how many people will do the stupid thing.
<nigel> Nigel: We should assume that people will always do any stupid thing that's available.
<nigel> Cyril: The consumer suffers when the author makes a mistake, I don't want that.
<nigel> Nigel: Are you saying that a note like Glenn's proposal in the comment would be helpful?
<nigel> Cyril: I wouldn't object to adding the note but the spec is okay as is.
<nigel> Glenn: Nigel is suggesting adding it to IMSC 1.2 and I have no objection to that.
<nigel> Cyril: I'm fine with that.
<nigel> SUMMARY: Consensus reached to add a note to IMSC 1.2 along the lines of @skynavga's comment earlier today. Comments from the Editor welcome.

[css-meeting-bot]

The Timed Text Working Group just discussed Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506, and agreed to the following:

• SUMMARY: Editor to prepare Pull Request

The full IRC log of that discussion

<nigel> Topic: Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506
<nigel> github: https://github.com/w3c/imsc/issues/506
<nigel> Nigel: Just checking in, since when we discussed this last the Editor was not present.
<nigel> .. Did the consensus last time make sense, Pierre? Any other questions.
<nigel> Pierre: Seems fine with me.
<nigel> .. But why in IMSC 1.2 instead of TTML2? We have to remove the may, but if folks think a note here would be
<nigel> .. useful that's fine. I'll change the wording a little bit but keep the intent.
<nigel> SUMMARY: Editor to prepare Pull Request
<nigel> Glenn: I would accept this under TTML2 in a future edition.
<nigel> Nigel: But I wanted it sooner so suggested put it in IMSC 1.2 now and TTML2 later.
<nigel> Glenn: There's some similar existing language in TTML already.
<nigel> Pierre: Okay, got it, thanks.