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

Hi Glenn,

I'm following this document, as per previous interactions on Github and here in the mailing list: https://w3c.github.io/ttml2/.

Sorry, I was imprecise about the [associate region] procedure and replication. In my mind, things got merged as that procedure is being called only as part of [construct immediate document].

Thank you for your step-by-step explanation. It was very helpful.

So, if I'm understanding correctly, the sole purpose of the rule 3 of [associate region] is to prevent that post-ordering processing of a whole subtree, where the region attribute is placed on a bottom element, make a parent to get excluded from the region itself.

Let's take this pre-association chunk for example:

```
<body>
	<div>
		<p>
			<span region="r1">...</span>
		</p>
	</div>
</body>
```

In this example, without the rule number 3 of [associate region], span would get preserved, but p, div and body wouldn't... which implies that either that span is also excluded or that we'd get something like this:

```
<region xml:id="r1">
	<span>...</span>
</region>
```

Which I can think it would be an incorrect flowing-into-region.

Which means that, theoretically, if we'd process everything linearly, from top to bottom without going to construct the intermediate document, we wouldn't be probably in need to have it, because we would already have the context where the element is placed and the regions that are active in that precise moment. Am I right?

What I'm trying to do, is to get back on the reasons of why things that exists are like this, in order to have a clear picture.

===

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

If I'm understanding correctly, then, ISD construction is performed in two steps, one described in [construct intermediate document] and one described Appendix J, the latter of which is optional, because after [construct intermediate document] I might not be wanting to generate another XML (with a root isd:isd element) but process directly and therefore obtain a sort of ISD which is not an XML. Is this correct?

===

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

I've read the whole 3.2.3 and the subsequent 3.3 sections.

3.2.3, step 4, reports

> The processor performs 11.3.1.3 Intermediate Synchronic Document Construction and 11.3.1.4 Synchronic Flow Processing.

However, I'm asking myself how much strict one must be when following 11.3.1.3 (and 11.3.1.4) if one wants to make reference to an implementation compliance statement (ICS, as per 3.3 Claims), if what counts is to obtain the same result (being on a rail) or if it counts to follow all the details like post-ordering processing (being on a tightrope).

3.3 Claims, also states in the note that

> Notwithstanding this requirement, it is possible to construct a TTML content processor that performs
> transformation or presentation processing functions and satisfies Generic Processor Conformance
> requirements but supports neither of the profiles required by Transformation Processor Conformance or
> Presentation Processor Conformance, and, instead, supports only profile(s) defined outside the scope of
> this specification. In such a case, the processor may be claimed to be compliant with Generic Processor
> Conformance, and, further, be a TTML transformation processor or a TTML presentation processor, but
> may not claim compliance with Transformation Processor Conformance or Presentation Processor
> Conformance.

Which can mean that, based on the strictness aforementioned, I could aim to the Generic Processor Conformance, isn't it?

My case is basically processing on runtime a TTML document (not yet an instance) and arrive to convert and extract each cue in a pre-existing known shape I have in my engine in order to be able to insert each one in a pre-existing data structure made on purpose to serve on time the cues, so having a bit of flexibility would be great, as I'm not sure yet if by following the exact steps, I can convert things to the structures I already have.

Thank you,
Alexander

Received on Wednesday, 21 August 2024 01:27:43 UTC