Regions association and inheritance clarification

w3c / ttml2

Timed Text Markup Language 2 (TTML2)

https://w3c.github.io/ttml2/

Other

41 stars 16 forks source link

Regions association and inheritance clarification #1274

Closed alexandercerutti closed 3 months ago

alexandercerutti commented 4 months ago

Hi, I was trying to understand better everything that concerns regions association in a document.

I'm following the TTML CR Snapshot.

When building the ISD, first of all the inline regions are processed and converted in out-of-line regions, only if the content element doesn't already belong a region attribute.

Then you proceed to associate a region R to the element (or make the element flow in to the region, I guess) when the matching conditions are met.

About the [associate-region] procedure, I have clear the points:

1 (direct association), 2 (inheritance), 4 (fallback) 5 (default)

But number 3 is what I cannot understand.

if the element contains a descendant element that specifies a region attribute [...], then the element is associated with the region referenced by that attribute;

Said that element is a Content Element and content elements are those specified in this list (Content module):

body, br, div, p, span

And said that a region attribute can be specified on these elements:

body, div, p, span, image

This paragraph confuses me as hell as in my head, a region should be assigned only from a parent element to all the children (rule number 2).

By the way, although I cannot find a specific reason for that specification (if you know where I can find more details on this, I kindly ask you to link it), I can accept it, even if I'm still in confusion.

Let's assume this snippet, where  is our Content Element:

<tt>
    <body>
        <div>
          <p>
              <span xml:id="el1" region="r1">
                  abcd
                  <span xml:id="el1.1" region="r2">...</span>
              </span>
              <span xml:id="el2">...</span>
              <span xml:id="el3" region="r3">...</span>
          </p>
        </div>
    </body>
</tt>

According to that paragraph, if I'm reading it correctly, the region="r1" is hence now applied to  when composing the ISD.

This leads to a couple of questions:

1) Said that el1.1 is also a descendant of p, I say r1 is applied but r2 isn't because, if I understood correctly, by the phrase "if a descendant element" it is intended that the lookup for a region should terminate at the first result. 1.1) Is this right? If so, what happens to r2? Is it applied only to eventual descendant of el1.1?

2) Does that mean that the content element becomes ... and therefore the rule number 2 of the above list enters in action? This would mean that all the children of  start to inherit properties from r1 (every property according to it's inheritance rules).

3) What happens, just like the case above, if two or more children have a region attribute? Do they merge on ? (so, does  flow in both?)

3.1) If yes, what if both regions own timing attributes? Who wins? 3.2) If no, I can guess that the lookup ends only at the first found, it doesn't matter the depth of the attribute.

4) The same questions apply if the content element is the body or the div.

Thank you very much!

nigelmegitt commented 4 months ago

My understanding of this is that an element can be associated with more than one region when the [construct intermediate document] process iterates through the regions in step 2.

In your example, the body, div and p elements all get replicated as descendants of the regions r1 and r3 because of the spans with ids el1 and el3. The spans with ids el1.1 and el2 get pruned always, for el1.1 because its region is not the same as the inherited region from el1, and for el2 because it has no region - and in this document, there's no default region, based on the assumption that you omitted either the head/layout/region elements or the child inline region elements that would have defined r1 and r2 for convenience in the example. When there's no default region, content elements that don't have any resolved region get pruned.

Hope that helps?

skynavga commented 4 months ago

@alexandercerutti please use the public-tt@w3.org mailing list to pose questions about usage or to request help in understanding the TTML specifications

alexandercerutti commented 4 months ago

@alexandercerutti please use the public-tt@w3.org mailing list to pose questions about usage or to request help in understanding the TTML specifications

@skynavga I was not aware of it. How is it organized and how does it differ with Github issues in the project organization?

Can I end this topic before moving to mailing lists? I surely have another unrelated question about a missing example, so I'll use the mailing lists for sure.

Also, can I suggest setting up an issue template for Github, in order to redirect to the appropriate way? I can create a PR if you wish.

Thank you.

@nigelmegitt having a reply, surely helps. First of all, thank you.

The spans with ids el1.1 and el2 get pruned always, for el1.1 because its region is not the same as the inherited region from el1, and for el2 because it has no region

Given your correct assumption (head/layout/region got ommitted), I understood perfectly the el2 getting pruned as rule °5 of [associate region] applies (the default region here is not available and therefore the °4 does not apply - as you said).

However, I don't clear which rule follows el1.1 to get pruned. Is it perhaps a conflict with rule °2? So, a region attribute is specified on an ancestor (el1), the element would be therefore associated with r1 but we are specifying a different region, so they "collide"?

I found some more details (in a Note under 1.2.1 Single Region Example):

Note also that one effect of placing region on body is to prevent any descendant element from being presented in a different region. This is because any such descendant would be pruned from presentation, as a consequence of the [construct intermediate document] procedure.

So we are basically saying that a higher region attribute (or inline region, otherwise) rules and locks every other children element... which I think it was implied in my mind, but to me not very clear in the specification at the [construct intermediate document] procedure. Am I right?

This note also makes me think that, if inline regions get converted in out-of-line regions with a region attribute reference, only one inline region is allowed in the chain itself.

Something like this:

<tt>
    <body>
        <div>
          <region tts:color="blue" />
          <p>
              <region tts:color="red" />
              <span xml:id="el3">text test</span>
          </p>
        </div>
    </body>
</tt>

Will lead to either to two possible cases I see:

 "inheriting the region attribute" from the parent and therefore the inline <region> children will get ignored;
 will get pruned as, when the ISD is build, inline regions are the first to be resolved.  should receive a region attribute inherently different from the one in <div>

Any reference you know, that I didn't find, that gives more details on this?

skynavga commented 4 months ago

@alexandercerutti please use the public-tt@w3.org mailing list to pose questions about usage or to request help in understanding the TTML specifications

@skynavga I was not aware of it. How is it organized and how does it differ with Github issues in the project organization?

It is a simple mail list. Not an issue management system. You can subscribe, unsubscribe, and send mail to the list. Click the ML link I provided for further info.

Can I end this topic before moving to mailing lists? I surely have another unrelated question about a missing example, so I'll use the mailing lists for sure.

Sure.

Also, can I suggest setting up an issue template for Github, in order to redirect to the appropriate way? I can create a PR if you wish.

Thanks, but that's not necessary. You are the only GH issue submitter asking usage and concept questions on this repo in the past few years (as opposed to using the TTWG's public ML).

nigelmegitt commented 3 months ago

However, I don't clear which rule follows el1.1 to get pruned. Is it perhaps a conflict with rule °2? So, a region attribute is specified on an ancestor (el1), the element would be therefore associated with r1 but we are specifying a different region, so they "collide"?

[construct intermediate document] step 3d prunes el1.1 from region r1 because it specifies that it is in region r2, and it prunes el1 and all of its descendants from region r2, including el1.1, because it is in region r1. Whichever way you go, it gets pruned.

I found some more details (in a Note under 1.2.1 Single Region Example):

Note also that one effect of placing region on body is to prevent any descendant element from being presented in a different region. This is because any such descendant would be pruned from presentation, as a consequence of the [construct intermediate document] procedure.

So we are basically saying that a higher region attribute (or inline region, otherwise) rules and locks every other children element... which I think it was implied in my mind, but to me not very clear in the specification at the [construct intermediate document] procedure. Am I right?

I think you have the correct conclusion, but I am not sure I agree about how clear it is in the specification!

This note also makes me think that, if inline regions get converted in out-of-line regions with a region attribute reference, only one inline region is allowed in the chain itself.

Any other elements with different inline regions would get pruned. It's not that they are not allowed, but the effect is that the element would never be presented. Note that there could be more complex results if conditionality is also brought in here.

Something like this:

<tt>
    <body>
        <div>
          <region tts:color="blue" />
          <p>
              <region tts:color="red" />
              <span xml:id="el3">text test</span>
          </p>
        </div>
    </body>
</tt>

Will lead to either to two possible cases I see:

* `<p>` "inheriting the region attribute" from the parent and therefore the inline `<region>` children will get ignored;

* `<p>` will get pruned as, when the ISD is build, inline regions are the first to be resolved. `<p>` should receive a `region` attribute _inherently different_ from the one in `<div>`

I think it is this second one.

On the point about continuing this discussion in the email reflector, that would certainly work. Another possibility in GitHub nowadays is to use the Discussions feature. So far we have not enabled that in this repository.

I will close this issue now (as TTWG Chair) - if you have follow-up questions please ask via the email reflector as discussed previously.

alexandercerutti commented 3 months ago

Thank you for your reply, @nigelmegitt. That helped a lot!

but I am not sure I agree about how clear it is in the specification!

I am a person that likes a lot explicitly explained things. The more a thing is explicitly explained, the better. I honestly would rather see thing repeated (like the body thing, in the ISD construction flow) than sparse in several points of the document. If I'm reading the ISD flow, I expect everything to be "self contained". I don't know if I explained myself correctly.

I already tried to use the mail list for a different question, but I'm still waiting for it to get reviewed and published.

About Github Discussion, I must say I find it more intuitive, easier to use and faster to use, as I'm already using my account. Using Discussions could improve the experience drastically to me.

skynavga commented 3 months ago

I am a person that likes a lot explicitly explained things. The more a thing is explicitly explained, the better. I honestly would rather see thing repeated (like the body thing, in the ISD construction flow) than sparse in several points of the document. If I'm reading the ISD flow, I expect everything to be "self contained". I don't know if I explained myself correctly.

@alexandercerutti it would appear you are not accustomed to reading technical standards, which effectively require you to read from the start to the end, circling back as needed; I agree it isn't easy, especially if you are used to reading hypertext documents that are subdivided into small easy to consume units; another thing to keep in mind is that most of the W3C standards are not intended to be used as user or implementation guides

alexandercerutti commented 3 months ago

@skynavga

it would appear you are not accustomed to reading technical standards

Yeah, maybe. I started like 2 years ago and I read to understand what who wrote specs wanted to achieve in the final implementation (a.k.a. the requirement). TTML is probably the most difficult I've encountered until now.

if you are used to reading hypertext documents that are subdivided into small easy to consume units

Well, I can say that no one prepared me for this! ahah

another thing to keep in mind is that most of the W3C standards are not intended to be used [...] as implementation guides

When I started reading it, I wasn't definitely expecting a guide, but I hoped to find something more friendly for beginners (intended as a "person that just started to read these docs", not a newbie developer). I think that deep diving inside such technical specifications is not something that all the developers do or will do, and maybe that's the reason.

I'm always of the idea that "if I don't understand something, probably some other people will have the same doubts", so I always try to bring improvements in whatever things I do.

I'm always grateful for your interventions, anyway.

skynavga commented 3 months ago

When I started reading it, I wasn't definitely expecting a guide, but I hoped to find something more friendly for beginners (intended as a "person that just started to read these docs", not a newbie developer).

@alexandercerutti None of the W3C standards or specifications are written for "newbie developers". I started work on the writing of TTML1 a little more than 20 years ago, circa 2003, at a time when I already had 30 years of coding and specification writing experience.

skynavga commented 3 months ago

@alexandercerutti for your entertainment, see the minutes of the first meeting (a telecon) of the TTWG

alexandercerutti commented 3 months ago

@alexandercerutti None of the W3C standards or specifications are written for "newbie developers". I started work on the writing of TTML1 a little more than 20 years ago, circa 2003, at a time when I already had 30 years of coding and specification writing experience.

I see what you mean. I opened the document and started to read. No one ever introduced me to these things. I have to start from somewhere ahah

@alexandercerutti for your entertainment, see the minutes of the first meeting (a telecon) of the TTWG

That's interesting, even if it was the first one.