Re: Clarification on ISD, regions flowing and compliance with standard

On Sun, Aug 18, 2024 at 8:30 PM Alexander Cerutti <
cerutti.alexander@gmail.com> wrote:

> Hi everyone,
>
> According to the specifications, an Intermediate Synchronic Document (or
> ISD) is the described way that an TTML implementation should follow to
> parse  and later present correctly a timed text.
>
> Specification also reports that content elements should flow inside the
> regions they are matched with according to the [associate region] procedure
> described under 11.3.1.3 Intermediate Synchronic Document Construction.
>
> That section reports that for each time interval, for each out-of-line
> region R, the whole sub-tree should be replicated, by pruning that are not
> associated to the region R by these rules:
>

Nothing under [associate region] pertains to replication. The [associate
region] procedure is performed in step 3 of the [construct immediate
document] procedure. By the time step 3 is evaluated, the replication
process has already been performed in the prior step 2 of the [construct
immediate document] procedure.

Step 3 evaluates (in a *postorder* traversal) the elements of the
previously replicated subtree (headed by the body element), determining
whether to prune some element(s) of this replicated subtree according to
steps 3a, 3b, 3c, and 3d, where pruning occurs if any of these substeps
evaluate to true.

The last substep 3d makes use of the [associated region] procedure, looks
up toward ancestors and then, if needed, looks down toward descendents,
where descendants have already been visited by the [associate region]
procedure and possibly pruned.

So, for a given element in this postorder traversal of the replicated tree,
rule 2 will win if an ancestor specifies a region attribute and is not
conditionally excluded (this is rule 2 of [associate region]). However, if
rule 2 doesn't match (no ancestor specifies a non-excluded region), then
rule 3 will be evaluated, in which case, if there remains a descendant
element D of the element being evaluated E and, and D specifies a
non-excluded region, then rule 3 wins.

Keep in mind that substeps a to d of step 3 of [construct immediate
document] are effectively evaluated in parallel (pruning occurs if any
substep is true). On the other hand, the rules of [associate region] are
evaluated in series (returning true when the first rule is satisfied).


>
> 1) if the element specifies a region attribute [...] the element is
> associated with the region referenced by that attribute;
> 2) if some ancestor of that element specifies a region attribute [...] the
> element is associated with the region referenced by the most immediate
> ancestor that specifies this attribute;
> 3) if the element contains a descendant element that specifies a region
> attribute [...] then the element is associated with the region referenced
> by that attribute;
> 4) if a default region was implied (due to the absence of any region
> element), then the element is associated with the default region;
> 5) the element is not associated with any region.
>
> While rules 1, 2, 4 and 5 makes complete sense to me, for what I
> understand, rule number 3 has the sole purpose of collecting the subtree
> until our deep element.
>
> Take this example I took from specification, and changed by assuming all
> the regions are different each other, in consideration:
>
> <tt tts:extent="640px 480px" xml:lang="en"
> xmlns="http://www.w3.org/ns/ttml"
> xmlns:tts="http://www.w3.org/ns/ttml#styling">
>
> <head>
> <layout>
> <region xml:id="r1"></region>
> <region xml:id="r2"></region>
> </layout>
> </head>
> <body xml:id="b1">
> <div xml:id="d1" begin="0s" dur="2s">
> <p xml:id="p1" region="r1">Text 1</p>
> <p xml:id="p2" region="r2">Text 2</p>
> </div>
> <div xml:id="d2" begin="1s" dur="2s">
> <p xml:id="p3" region="r2">Text 3</p>
> <p xml:id="p4" region="r1">Text 4</p>
> </div>
> </body>
> </tt>
>
> As explained in the specification, for the open interval [0s, 1s), we'll
> have a theoretical ISD that include "p#p1" and "p#p2", divided by region.
> For what I'm understanding, the rule number 3 serves only to this purpose:
> to create a full-subtree replica from body to an element with the same
> region id.
>

Let's take your example, and walk through the [construct intermediate
document] process for active interval [0s, 1s).

Step 1 doesn't apply since there are no inline regions.

For step 2, both regions r1 and r2 are temporally active over the entire
root temporal extent since they don't specify begin or end. So we need to
replicate the sub-tree headed by body for each of r1 and r2 in turn. Let's
start with R=r1 and create a copy of the subtree rooted by body for r1,
call it r1body. We will also do the same for r2, and call the copy r2body.

For step 3, we will start with r1body which we will traverse by post-order
(effectively bottom up). Also, let's ignore the whole business of anonymous
text elements for this description. In this evaluation order, we visit the
following elements (in order): p1, p2, d1, b1 (but not r1, since we started
at r1body). Now, starting with p1, none of steps 3a, 3b, or 3c are true, so
let's check 3d.

Step 3d entails running the [associate region] procedure, and we see that
rule 1 of [associate region] is satisfied (p1 specified region r1). We now
skip the remaining rules 2-5, and associate p1 with r1.

We do the same for p2, and we see that [associate region] step 1 is again
satisfied, so associate p2 with r2. However, in this case r2 is not R, so
we prune p2 from r1body.

We do the same for d1, but see that [associate region] rules 1 and 2 are
false; however rule 3 does give an answer, since the only descendant at
this point is p1 which is associated with r1. So d1 is associated with r1.

The same procedure applies for r1body (originally replicated by performing
a deep copy of b1), and see that r1body is associated with r1 as well (by
rule 3).

Now, by steps 4 and 5, we see that r1body is non-empty, so we reparent it
to r1.  Then we repeat the procedure for R=r2 and r2body, which result is
reparented to r2, finally yielding (with some additional rewriting of ids
to maintain XML compliance):

<tt tts:extent="640px 480px" xml:lang="en"
xmlns="http://www.w3.org/ns/ttml"
xmlns:tts="http://www.w3.org/ns/ttml#styling">
<head>
<layout>
<region xml:id="r1">
<body xml:id="r1b1">
<div xml:id="r1d1">
<p xml:id="r1p1">Text 1</p>
</div>
</body>
                        </region>
<region xml:id="r2">
<body xml:id="r2b1">
<div xml:id="r2d1">
<p xml:id="r2p2">Text 2</p>
</div>
</body>
                        </region>
</layout>
</head>
</tt>

If it desired that this be transformed into actual ISD documents as
described by Appendix J, then some additional (unspecified) processing will
be required.

Once the ISDs have been created as above, either conceptually or concretely
(Appendix J), the next step will be to perform 11.3.1.4 Synchronic Flow
Processing, during which time style resolution (including style
inheritance) is performed.


>
> However, a content element associated with a region due to rule number 3
> doesn't inherit anything from the region itself, because that would mean
> for the body, div and all the middle elements between body and the element
> that has the region attribute, to get eventual style or timing attributes
> (that will be later pruned) or other things, which are not supposed to get.
>

Incorrect. See my above description.

I'm I right on this reasoning? Because if I'm not, I do not explain myself
> how a processor could correctly merge shared elements in adjacent
> synchronic document instances, when a (for example) shared division element
> can contain different elements that flowed in different regions. This would
> mean that there should be explained a strategy for resolving conflicts or
> applying a priority factor on conflicting things, but I really really
> really hope this is not the case.
>

No merging or conflict resolution is required if you follow the procedure I
elaborated above.


> I'm now going to add a bit.
>
> By recalling what specification says about the terms "may", "should" and
> "must" in the top of the document, nor the [construct intermediate
> document] procedure, nor it parents, seem to specify any of the quoted
> terms.
>

You seem to have missed the following statement in 2.3:

"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."

See also the note that follows this language for an example.


>
> So, what I am asking is: how much a processor / presenter implementation
> should adhere to the ISD procedure? Is it normative or it isn't? Can steps
> be skipped if the implementation doesn't follow the ISD steps one-on-one
> and still be considered compliant?
>

Failing to support the "ISD procedure" would violate the requirements of
criteria 4 of Section 3.2.3 Presentation Processor Conformance. So, if a
given processor claims to support the #presentation feature and does not
follow the "ISD procedure", then that claim would be false.


>
> Is compliance with the TTML standard based only on the profiles (e.g. DFXP
> Profile) or there's something else I'm missing?
>

Assuming that by "TTML standard" you mean TTML2 2nd Edition Candidate
Recommendation of 28 January 2020
<https://www.w3.org/TR/2020/CR-ttml2-20200128/>, then everything relative
to conformance is covered by Section 3 and its references.


>
> Thank you,
> Alexander.
>
>

Received on Monday, 19 August 2024 05:08:19 UTC