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

just a few preliminary remarks (inline); i will send longer response
presently;

On 5/19/09 2:33 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
 
> The first thing I have discovered is that there are indeed issues in the
> timing behavior described by the current WD.
> 
[GA] agreed, and i think you are heading in the correct direction on
resolving the clear timer semantics,  however i have some slightly different
conclusions which I will elaborate in a forthcoming, longer response;

> The next problem is that the two timers are not independent, and we have the
> clear operation effectively performing a fill and resetting the fill timer,
> therefore the rate of flow through the region  doesn¹t stay  constant
> throughout. What I think was intended seems to have been a queue process which
> is trying to feed content in at one end, and take it out of the other,
> maintaining as much as possible a full pipeline and constant speed.
>  
[GA] but they [the two timers] are indeed independent, and are governed by
different periodicity rules; having the trigger action off one timer reset
or trigger the other upon various conditions does not make them dependent,
it just makes the semantics of their trigger actions inter-dependent;
> 
> Now we have cleanly separated the two timers. If we adopt this fix (which I
> think we need to otherwise the model is pretty unusable), it probably makes
> sense to define that the clear interval is always the same as the fill
> interval, and that both are controlled by the inter parameter.
>  
[GA] i believe they are already ³cleanly separated²; they have independent
timer states and different trigger actions; john¹s examples already show
scenarios for having different periodicities, so they should not be required
to be the same;
> 
> I still think it would be better to combine the fill and clear operations into
> a singled timed operation which would simplify the exposition considerably,
> Also there seems to be nothing in the current draft which actually corresponds
> to the original meaning of the inter-fill timing; which was a pause between
> determining a clear is required and actually performing the clear.
> 
[GA] but that is precisely the intended definition of the currently
specified clear timer; if it was specified badly and doesn¹t achieve this
result, then we need to fix it;
> 
> Having possibly dealt with the timing issue and played around with the various
> modes, I¹m now concerned we are going to a lot of trouble to specify a complex
> processing model, despite the fact that only a few combinations of in and out
> unit actually make practical sense.
>  
[GA] i don¹t view it as a ³complex processing model² at all; the fact that
you could implement a simulator over the weekend would seem to argue that it
is simple, not complex; the reason for the model is to be precise about
semantics and the intended result; all too often in specifications these
details are left at the mercy of the implementer, and different
implementations end up with very different behaviors, or one implementation
begins to serve as a de-facto golden standard; i want to avoid that here by
being as precise as possible: meaning that behavior is standardized,
reproducible, and testable; i agree that it makes the specification process
more complex, nevertheless, both implementers and authors benefit from more
precisely defined behavior;
> 
> The main problem is that XSL:FO line breaking rules don¹t admit a break at an
> arbitrary point; (and I believe we at one point decided not to require complex
> hyphenation processing although I haven¹t traced that decision down yet).
> Whereas I believe John was basing his design on a teletext like model which
> places individual characters, and breaks words at arbitrary points.
>  
[GA] this is not true; XSL-FO does not specify line breaking rules,
therefore it is completely arbitrary, or at least non-standardized; DFXP 9.4
and XSL 1.1 4.7.2 (3) apply. Notice the definitions of the script and
language properties of XSL 1.1, where you will find the following:

> Specifies the {language,script} to be used by the formatter in
> language-/locale-coupled services, such as line-justification strategy,
> line-breaking, and hyphenation.
> 
> Note:
> 
> This may affect line composition in a system-dependent way.
> 
> Thus in timed text when applying wrapping, line breaks basically occur at
> whitespace boundaries, as in HTML.
> 
[GA] at present, what constitutes a legal line break in DFXP remains
non-standardized (as in XSL), so it is arbitrary; therefore, there is no
problem implementing snake mode at the character or glyph level of flow
units;