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

On Tue, Aug 20, 2024 at 8:27 PM Alexander Cerutti <
cerutti.alexander@gmail.com> wrote:

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

No, this (the above) would not happen. When you prune an element, say the
`<p/>` element in this example, then the `<span/>` would go away.

In any case, you are asking a hypothetical question. We do indeed have rule
3, so don't spend any time considering what TTML would be without it.


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

No. And the notion of linearity doesn't really apply either. You will need
to traverse the DOM tree multiple times, sometimes in pre-order and
sometimes in post-order to obtain the required results. There may a optimal
node visitation model that eliminates some of these traversals, but that is
beyond the scope of this thread.

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

I'm afraid you are wasting your time. To cite Tennyson's Charge of the
Light Brigade: "Theirs not to make reply, Theirs not to reason why, Theirs
but to do and die."


> ===
>
> > 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?
>

Speaking generally, yes.


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

11.3.1 prologue says

"Any implementation is permitted provided that the externally observable
results are consistent with the results produced by this model."


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

True. But it would be a useless claim. Anyone that wants to actually use
your work will want either (or both) "Transformation Processor Conformance
or Presentation Processor Conformance."


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

It sounds like you don't want to implement the specification as defined.
That's fine, but not very useful to the community or to this mailing list.


> Thank you,
> Alexander
>
>
>
>

Received on Wednesday, 21 August 2024 04:57:34 UTC