Re: ISSUE-98 (Clear timing.): Eliminate separate clear timing from dynamicFlow [DFXP 1.0]

inline

On 5/15/09 5:49 PM, "Timed Text Working Group Issue Tracker"
<sysbot+tracker@w3.org> wrote:

> 
> ISSUE-98 (Clear timing.): Eliminate separate clear timing from dynamicFlow
> [DFXP 1.0]
> 
> http://www.w3.org/AudioVideo/TT/tracker/issues/98
> 
> Raised by: Sean Hayes
> On product: DFXP 1.0
> 
> I can see no justification for having separate clear timing in any of the
> examples from John Birch¹s original documents (the only hard evidence I can
> find in the history trail of a design discussion). The notion of a separate
> clear timer seems to have been added between the March 14 draft and March 21
> draft without discussion on the public list. What is more, the presence of a
> separate clear interval seems at somewhat at odds with the behavioral
> requirement.

[GA] I guess you are referring to the 2005 WDs. In any case, the notion of
clear timing was present in the draft Timed Text 1.0 Fill Module [1], from
as early as May 2004, where it is included in the concept of temporal
inter-fill interval, which is the origin of our current syntax expressed by
the inter() flow interval function.

[1] 
http://lists.w3.org/Archives/Member/member-tt/2004Sep/att-0036/fillscroll_JB
.html

In the March 14, 2005 WD, this was defined at [2], and expressed in terms of
clearing (and reflowing) content, as follows (emphasis added):

[2] 
http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050314/#style-attribute-dynamicFlo
w

> If one <duration> value is specified, then it denotes the time interval to
> wait between dynamic fill insertions. If two <duration> values are specified,
> then the second denotes the time interval to wait prior to clearing content
> from and flowing content within the region after the region has become full as
> a result of a dynamic fill insertion. The former <duration> is referred to as
> the fill interval, while the latter is referred to as the inter-fill interval.

The enhanced definition in the March 21, 2005 WD was the result of
elaborating the syntax and the accompanying prose, so there was no new
concept being added there. Indeed, see [3] where an improved syntax was
being discussed on March 15, 2005, where it is referred to as
interFillInterval.

[3] http://lists.w3.org/Archives/Member/member-tt/2005Mar/0030.html

Then there was the lengthy discussion of dynamic flow semantics, including
clear timing, a few weeks later on Days 2 and 3 (April 12-13, 2005) of the
face-to-face meeting in Cupertino [4], at which you were present (and
actively discussing given your recorded comments at the time).

[4] http://lists.w3.org/Archives/Member/member-tt/2005Apr/0011.html

There seems to be a good dialogue recorded on the issues of independent
timers by John and I at [7] in early 2006, in his review of what was (then)
to be published in Appendix B.

[7] http://lists.w3.org/Archives/Member/member-tt/2006Feb/0015.html

I note that in the above citation that John¹s model for this ³inter-fill
interval² is not exactly the same as, but is more comprehensive than the
strict notion of a clear timer interval as we have presently defined it:

> ³The inter interval is intended to define a period when the display must be
> stationary, this would typically be after a fill event. So for example a new
> line is added to the display, the display remains static for a period, then
> clear, reflow and fill events may again take place. For a smoothly scrolling
> region, the inter interval would be defined as 0.²

He goes on to say:

> ³Is it possible that for a completely comprehensive model we need three
> timers, or perhaps a better way of defining how flow events may be related?
> 
> I personally think two time values are sufficient, one to set the rate of new
> flow units... the second to enforce a period of stasis on the display to allow
> easy reading. I do not consider it useful to be able to set a delay interval
> between a clear operation and a susequent reflow... but others may have a
> different view.
> 
> Perhaps the timing would be best defined as
> 
> * a fill interval (period between fill operations) - thus setting flow rate
> through presentation container... A master interval that by definition
> constrains other intervals.
> * a post clear delay (period after clear but before any reflow)
> * a post reflow delay (period before any subsequent fill)
> * a post fill delay (period after a fill operation - before any subsequent
> clear)
>      
> Of course by defining the fill intreval and two of the above delays, the third
> delay is effectively defined. The only other wrinkle is that if events are
> synchronous, e.g. A synchronous clear and reflow, but a non synchronous fill.
> In these cases, I would suggest that the valid delay would be the value
> associated with the last logical operation in a synchronous set of operations.
> So in the just preceeding example (synchronous clear and reflow) the reflow
> delay would be valid, but the clear delay would be ignored....
> 
> For smooth scrolling only one interval is required (the fill rate), plus the
> indication that all flow events are coupled and synchronous. The post fill
> delay is zero indicating that all of the fill interval is to be used by the
> transitions of the flow operations.
> 
> For paused scrolling two intervals are required, (the fill rate), a stasis
> time for an interval between the fill and a clear (the post fill delay), plus
> the indication that all flow events are coupled and synchronous.²
>  
Notwithstanding John¹s further comments in [7], my original formulation of
Appendix B was an attempt to formalize the Temporal Flow Model described in
[1]. In my attemt to formalize the Temporal Flow Event Timing of [1], I
interpreted ³after the fill interval (i.e., at t = t + fill interval)² to
mean the time at which the fill timer expires, and I interpreted ³after the
inter-fill interval (i.e., at t = t + inter-fill interval)² to mean the time
at which the clear timer expires. In this context, I mapped the value
computed by the intra() flow interval function to the notion of fill
interval and the value computed by the intra() flow interval function to the
notion of inter-fill interval. Notice that the text of [1] refers to these
two events as fill event(s) and clear event(s), respectively. So I think the
terminology I used in Appendix B is consistent with [1].

> 
> If I have a two line caption region , and I wish to flow the text through it,
> with text entering at a word rate and leaving at a line rate. Then I don¹t
> want a clear to occur until after two lines have been added, but then I want
> to clear the lines after each additional line is completed; which implies
> clear timing can¹t start until the region starts to overflow, so the first
> clear interval needs to be extended, and after that we want the clear interval
> to be synchronized with the fill interval which is based on irregular length
> words, so a single value seems inappropriate.
> 
> In the example flow below: The first clear/reflow occurs at t14, the next at
> t20, then at t27 and at t33  (clear intervals of 14, 6, 7 6), then we
> presumably want to clear the remaining two lines to be cleared in some manner.
> 
> T01 Alice
> 
> t02 Alice was
> 
> Š.
> 
> t06 Alice was beginning to get very
> 
> t07 Alice was beginning to get very
>        tired
> 
> Š.
> 
> t13 Alice was beginning to get very
>        tired of sitting by her sister on
> 
> t14 tired of sitting by her sister on
>        the
> Š
> T19 tired of sitting by her sister on
>         the bank and of having nothing
> 
> T20 the bank and of having nothing
>         to
> Š.
> 
> T26 the bank and of having nothing
>         to do: once or twice she had
> 
> T27 to do: once or twice she had
>         peeped
> 
> T33 peeped into the book her sister
>         was
> 
> T34 peeped into the book her sister
>         was reading
> 
> 
> 
> 
>