Allow detection of the EBU-TT-D content profile.

[palemieux]

The [construct effective content profile] does not allow the effective content profile to be set by inspection of the document, beyond the values of ttp:contentProfiles and ttp:profile.

This prevents TTML2 profiles such as IMSC1.1 to determine that a document conforms to EBU-TT-D (and thus IMSC1.1) since EBU-TT-D signals content profiles using the ebuttm:conformsToStandard element.

Propose to add step at [construct effective content profile] allowing the effective content profile to be determined by the document processing context.

[palemieux]

The other instance where the external processing context needs to set a content profile is when no profile is signaled in band, but instead out of band, e.g. in the media container.

[skynavga]

Let me remind all that the only reason to signal or set a content profile is to enable validation processing. If the intention of signaling a profile is to determine support requirements, then it is a processor profile that should be signaled. In other words, relying on inference of processor profile from content profile is not a good approach, in general.

…

On Sat, Oct 21, 2017 at 1:13 AM, Pierre-Anthony Lemieux < ***@***.***> wrote: The other instance where the external processing context needs to set a content profile is when no profile is signaled in band, but instead out of band, e.g. in the media container. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#467 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb3vz8yVp0t0Z3EmrGncO1V1FuFxKks5suZl9gaJpZM4P5h74> .

[palemieux]

@skynavga Below is the specific case I had in mind.

Given a TTML1 document that

• conforms to IMSC1 Text
• does not explicitly signal conformance to IMSC1 Text profile through either ttp:profile or ebuttm:conformsToStandard information (this is permitted in IMSC1, and not unexpected given the limited profile signaling mechanisms in TTML1 and industry practices at the time)
• is transmitted using a mechanism, e.g. ISOBMFF container, that signals that the document in fact conforms to IMSC1 Text, e.g. through a content type parameter

In that case, the external processing context should able to override the effective processor profile to the IMSC1 Text profile.

[skynavga]

On Sat, Oct 21, 2017 at 10:48 AM, Pierre-Anthony Lemieux < ***@***.***> wrote: @skynavga <https://github.com/skynavga> Below is the specific case I had in mind. Given a TTML1 document that - conforms to IMSC1 Text - does not explicitly signal conformance to IMSC1 Text profile through either ttp:profile or ebuttm:conformsToStandard information (this is permitted in IMSC1, and not unexpected given the limited profile signaling mechanisms in TTML1 and industry practices at the time) - is transmitted using a mechanism, e.g. ISOBMFF container, that signals that the document in fact conforms to IMSC1 Text, e.g. through a content type parameter In that case, the external processing context should able to override the *effective processor profile* to the IMSC1 Text profile.

First, this is not an override scenario, since there is no specified ttp:profile. Second, this scenario is already supported by the existing spec text without any change, see step (1) of [construct default processor profile]. I note that this (above) scenario is different from the original description of this issue which is framed in terms of content profile and not processor profile and in terms of document processing context and not document interchange context.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#467 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb6KX1u5yU_zO8CIFYMtkXjaSpEtcks5suiBIgaJpZM4P5h74> .

[palemieux]

First, this is not an override scenario, since there is no specified ttp:profile.

Yes, the scenario above includes the situation where ttp:profile is specified, e.g. indicates conformance to http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full, but the document is otherwise conformant to IMSC1... in which case the default processor profile does not apply.

[palemieux]

I note that this (above) scenario is different from the original
description of this issue which is framed in terms of content profile and
not processor profile and in terms of document processing context and not
document interchange context.

You are right. I would think both the document interchange context and document processing context ought to be able to override (or inject a profile into) the profile resolution algorithm. Happy to create a separate ticket, but it might make more sense to expand the scope of this one.

[skynavga]

Let's not open an additional issue. What I implemented in the PR is - add document processor context override step for construct effective content profile - add document processor context override step for construct effective processor profile I believe this covers all the scenarios I have seen discussed. The only open question in my mind is whether we want to allow the document processor to override an explicit author signaling of content profile. The first step above allows this. I don't have any problem with this, e.g., the receiving entity might tell the processor to force the use of a specific content profile for some application specific purpose. However, I would not be averse to adding an informative recommendation to the effect "*notwithstanding the above, a processor should not override an explicit specification of content profile unless there is a clear, application specific reason to do so."*

…

On Sat, Oct 21, 2017 at 3:45 PM, Pierre-Anthony Lemieux < ***@***.***> wrote: I note that this (above) scenario is different from the original description of this issue which is framed in terms of content profile and not processor profile and in terms of document processing context and not document interchange context. You are right. I would think both the document interchange context and document processing context ought to be able to override (or inject a profile into) the profile resolution algorithm. Happy to create a separate ticket, but it might make more sense to expand the scope of this one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#467 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb5BZSGpaZbvUrgjmOQQBlYESx35aks5sumYEgaJpZM4P5h74> .

[css-meeting-bot]

The Working Group just discussed Allow detection of the EBU-TT-D content profile. #467, and agreed to the following resolutions:

• SUMMARY: Modulo the minor text edits required, this is good to merge.

The full IRC log of that discussion

<nigel> Topic: Allow detection of the EBU-TT-D content profile. #467
<nigel> github: https://github.com//issues/467
<nigel> Nigel: To discuss the pull request:
<nigel> -> https://github.com//pull/468 Add document proceessing context override semantics for effective con… #468
<nigel> Nigel: There's one easy fix here about an element being called an attribute, and a typo.
<nigel> Glenn: I'll get those in and maybe we can wrap that one up.
<nigel> .. Pierre, if you have any additional comments on this please say so, in the thread.
<nigel> Pierre: The proof will be when we see how IMSC 1.1 uses this, in terms of how the global
<nigel> .. override works.
<nigel> .. A global override like is suggested here will work for IMSC. When we walk through the
<nigel> .. revamped IMSC 1.1 profile resolution section, which is the first user of this TTML2
<nigel> .. functionality, we'll see if there are any issues. In the meantime I think this pull request
<nigel> .. addressed the major issue, which is there used to be no way to provide an external
<nigel> .. input to the process, so that's been fixed.
<nigel> Glenn: It already did support the document interchange context providing a value if there
<nigel> .. was no other value than that chosen so far. You had explicitly asked that it pertained
<nigel> .. to the document processing context as opposed to the document interchange context.
<nigel> Pierre: That's right.
<nigel> Glenn: I took that to mean you wanted a way for the processor to look inside the document
<nigel> .. and make a determination based on the document content or on the entity that's controlling
<nigel> .. the application.
<nigel> Pierre: Yes but there's also an issue with the document interchange context, that it comes
<nigel> .. after everything else, only if everything else failed.
<nigel> Glenn: That's right, that particular mechanism did not provide an override path, which is why
<nigel> .. I ended up combining the original request along with an override.
<nigel> Pierre: Exactly, so right now the new language supports that.
<nigel> .. Which is fine.
<nigel> .. We'll try with IMSC 1.1 and see if it works.
<nigel> SUMMARY: Modulo the minor text edits required, this is good to merge.