Further constrain ruby descendants (#372).

[skynavga]

Closes #372.

[cconcolato]

I still think the text is too verbose. We should find another way, more compact, maybe more formal to express those constraints.
Also, the use of 'is' instead of 'must' is confusing in:

if the computed value of tts:ruby is container, then the
computed value of tts:ruby of all ancestor elements is none;

It should be:

if the computed value of tts:ruby is container, then the
computed value of tts:ruby of all ancestor elements must be none;

[skynavga]

@cconcolato no, can't do that (change to "must"); we try to use constraint language consistently in TTML2, which uses declarative statements with "is" not "must"; see also the text under Conventions:

If normative specification language takes an imperative form, then it is to be treated as if the term must applies. Furthermore, if normative language takes a declarative form, and this language is governed by must, then it is also to be treated as if the term must applies.

Note:

For example, the phrases "treat X as an error" and "consider X as an error" are to be read as mandatory requirements in the context of use. Similarly, if the specification prose is "X must apply", "X applies", or "X is mandatory", and "X" is further defined as "X is Y and Z", then, by transitive closure, this last declarative phrase is to be read as "Y is mandatory" and "Z is mandatory" in the context of use.

Doing as you suggest would require making thousands of changes throughout the text, which clearly we are not going to do.

[cconcolato]

It is fine in many places to use the "imperative" form. I note that this is not the case everywhere, e.g. the use of 'must' in the following sentences:

When an image appears in an image defining context the following additional constraints apply:

• attributes animate, begin, dur, end, region, and timeContainer must not be specified, and, if they appear, must be ignored for the purpose of presentation processing;
• elements from the Animation.class element group must not appear as child elements, and, if they appear, must be ignored for the purpose of presentation processing.

I feel it would be more appropriate in this case to use 'must'.

[cconcolato]

About the conciseness, can you at least avoid repeating "if the computed value of tts:ruby is container" 5 times and others 6 or 7 times, e.g. by using sub-bullets?

[skynavga]

On Wed, Jan 31, 2018 at 1:59 PM, Cyril Concolato ***@***.***> wrote: About the conciseness, can you at least avoid repeating "if the computed value of tts:ruby is container" 5 times and others 6 or 7 times, e.g. by using sub-bullets?

That is strictly editorial tweaking, which we can do at any time in the future. We have more important matters to work at present. Please approve the PR unless you find a substantive breakage.

…

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

[skynavga]

@cconcolato to elaborate, the constraints on ruby content are mandatory for the support of tts:ruby, because:

&3.1.5 (5)
The reduced xml infoset satisfies all additional mandatory syntactic and semantic constraints defined by this specification.

3.2.1 (5)
If the processor supports some optional processing semantics defined by this specification, then it does so in a manner consistent with the defined semantics.

10.2.35
When using tts:ruby, the following nesting constraints apply:
...

I realize you may be accustomed to other conventions in different SDOs or WGs or documents, but this is what we have with TTML, and we aren't going to change it now.

As for making minor, editorial tweaks to improve reading: while they may be considered useful for some readers, others will find what we have sufficient. At this juncture, I prefer we focus on substantive issues, and not word-smithing.

[skynavga]

@cconcolato thanks!

[nigelmegitt]

I'm not sure I know enough about ruby processing and presentation to review this. The language around constraints is a little strange, since they are effectively SHALL requirements that avoid using that conformance language, but that does seem editorial.