Fix typos.

[skynavga]

Need to fix the following typos:

• in Table E-1, #background should be marked for version 2, not 1;
• in Table E-1, #background-image should be marked for version 2, not 1;
• in Table E-1, #contentProfiles should be marked as mandatory, not optional;
• in Table E-1, #inferProcessorProfile should be marked as mandatory, not optional;
• in Table E-1, #permitFeatureNarrowing should be marked as mandatory, not optional;
• in Table E-1, #permitFeatureWidening should be marked as mandatory, not optional;
• in Table E-1, #transformation-version-2 should be marked for version 2, not 1;
• in profiles/ttml2-{presentation,transformation}.xml, #core should follow #contentProfiles;
• in E.1.161, tts:rubyAlign-withBase should be changed to tts:rubyAlign and the href fragment id similarly updated.
• update Table E-2 to match what is in Table E-1;
• update Table E-3 to match what is in Table E-1;

Check off as added to some PR.

[nigelmegitt]

@skynavga Why should the profile-related features be marked as mandatory not optional? This is non-obvious.

[skynavga]

@nigelmegitt They already are (in the profiles docs), this PR is just to make the table consistent. As for why, #profile was mandatory in TTML1, so #profile-version-2 is mandatory in TTML2. This has been in the previous WDs, so not new here.

[nigelmegitt]

@skynavga it might not be new, but it is not obviously correct.

#profile was significantly simpler than #profile-version-2 - why does the latter need to be mandatory?

[skynavga]

Because #profile-version-2 is required to obtain TTML2 profile semantics. Can we just fix the editorial problem that this issue documents rather than discussing the rationale for the feature being required, which is orthogonal. You can raise that as different issue for CR2.

[nigelmegitt]

Can we just fix the editorial problem that this issue documents

Not really, because folk like me might have taken the alternate view that the error was in the profile document (i.e. in appendix G.2).

Because #profile-version-2 is required to obtain TTML2 profile semantics.

@skynavga Right, but that's not an argument that it must be listed as a required feature in table E-1 and appendix G.2.

The question to ask here is: if a [transformation | presentation] processor were not to implement, say, #contentProfiles, could it still process some useful set of document instances? There is a significant class of processors targeted at a specific usage such as players in a vertical platform, that simply do not need to support those profile-related feature designators, and that can process the features they do understand.

By marking the features as required, my concerns are that a) such processors could not be classed as TTML2 processors and b) someone could argue that they should be excluded from the implementation report.

[nigelmegitt]

Add to this issue: E.1.161 #rubyAlign-withBase refers to the style attributes tts:rubyAlign-withBase with an href that points to #style-attribute-rubyAlign-withBase - in both cases that looks like a copy/past error and the -withBase part should be deleted.

[skynavga]

@nigelmegitt the simple fact that they are listed in the profile documents is sufficient evidence that table E-1 is incorrect; we can either fix this editorial inconsistency now and then address the issue of whether we want things this way separately in CR2 or we can do nothing now and go out the door with an easily fixed inconsistency;

[nigelmegitt]

@skynavga why do you assert priority of Appendix G.2 over Table E-1?

[skynavga]

@nigelmegitt I assert that Appendix G was changed and that the corresponding changes in E-1 were inadvertently left out; priorities don't matter

[nigelmegitt]

I've raised #683 - if we resolve in favour of that issue then some of the changes requested here will not be needed.

[skynavga]

@nigelmegitt re: #678 (comment), any resolution to #683 will be after CR1 is published