Remove support for tts:position on <tt>?

[palemieux]

What is the use case for tts:position on <tt>? The origin of the root container on a related media project will be determined by an external container/context.

Profiles could always prohibit tts:position on <tt>, but might as well not include it unless there is a need for it.

[skynavga]

It allows the author to provide a indicated positioning preference, which the document processing context can consider as a desired position, which it can then use or override as appropriate. We could define a feature designation for this usage if needed.

[palemieux]

Unless a user explicitly requested this feature, I recommend removing it in the spirit of reducing the number of test cases and the potential for issues.

[skynavga]

At this point, it is already in the spec, so it increases the editorial burden at this time. It would be better to cull at end of CR if there aren't two implementations.

[palemieux]

Culling it now is trivial. Remove the following:

tts:position = xsd:string from XML Representation – Element Information Item: tt

and

If the tts:position attribute is specified on the tt element, then it must adhere to 10.2.33 tts:position, in which case it specifies the position of the root container region relative to a reference positioning rectangle.

and

tts:position from Except for the tts:extent and tts:position attributes described above

It will be simpler than defining a new feature and generating test cases.

[nigelmegitt]

This falls into an interesting class of information: stuff that relates the TTML document instance's contents to a presentation context; in general there may be multiple presentation contexts that apply for any one document instance, but only a single attribute value operates on the root element. This is the same class that mediaOffset falls in - something that may be true once but may not be true in other cases.

I'm not clear what the use case for this information class is at all - probably it is for tunnelling data that is expected to be extracted and moved across into a wrapper object for distribution purposes. Since the presentation context may vary there's an argument for removing this altogether; similarly there's an argument for putting it into conditionally processed elements so that the presentation context can be used to select the appropriate presentation values. Including such information as an attribute on the root tt element prevents that, or alternatively forces the creation of multiple document instances, one per presentation context.

What I'm trying to argue here is that we should drop this class of information or move it into metadata or some other newly named information class. I don't think we can sensibly create an interoperable solution without more clarity about how it will be used.

By the way, in the particular case of tts:position the default value has the equivalent behaviour to the IMSC 1 requirement to position the root container region centrally in the case that it has a different aspect ratio to the related media. Allowing the attribute to be explicitly set allows for other positioning rules to be specified.

[skynavga]

On Fri, May 19, 2017 at 3:50 AM, Nigel Megitt ***@***.***> wrote: This falls into an interesting class of information: stuff that relates the TTML document instance's contents to a presentation context; in general there may be multiple presentation contexts that apply for any one document instance, but only a single attribute value operates on the root element. This is the same class that mediaOffset falls in - something that may be true once but may not be true in other cases. I'm not clear what the use case for this information class is at all - probably it is for tunnelling data that is expected to be extracted and moved across into a wrapper object for distribution purposes. Since the presentation context may vary there's an argument for removing this altogether; similarly there's an argument for putting it into conditionally processed elements so that the presentation context can be used to select the appropriate presentation values. Including such information as an attribute on the root tt element prevents that, or alternatively forces the creation of multiple document instances, one per presentation context. What I'm trying to argue here is that we should drop this class of information or move it into metadata or some other newly named information class. I don't think we can sensibly create an interoperable solution without more clarity about how it will be used. By the way, in the particular case of tts:position the default value has the equivalent behaviour to the IMSC 1 requirement to position the root container region centrally in the case that it has a different aspect ratio to the related media. Allowing the attribute to be explicitly set allows for other positioning rules to be specified.

Thanks for reminding me of the use case that drove adding this.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#319 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb158XMEP01bP4Yaj0O7kKL-C-2_mks5r7WXzgaJpZM4NeZy0> .

[palemieux]

Positioning of the root container on the related media object should be left to applications and/or profiles, since they vary so much, so I still think this feature ought to be removed from TTML2.

[skynavga]

Since both TTML1 and TTML2 already state

In the absence of other requirements, and if a related media object exists, then it is recommended that the document processing context determine that:

• the origin of the root container region be established so that this region is centered in the related media object region.

I am open to dropping it.