Re: Draft response (Re: DFXP LC Comments - Issue 10 Response; Bert Bos)

Dear Bert,

Thank you for your responses [1] to our initial response [2] to your
comments [3] to DFXP WD LC [4]. The TT WG has carefully considered
your further comments and follow-on responses, and has agreed to the
following follow-on responses, which are labeled with "[TTWG Response
2005-10-27]". To reduce clutter, we have removed from below the
comments for which you had no further response or comment.

At this time, we do not expect any further responses; however, you
are free to comment or respond further if desired.

Regards,
Glenn

------------------
Glenn Adams, XFSI; Cambridge, MA; (e) glenn at xfsi dot com
Chair Timed Text Working Group (TT WG)
------------------

Citations

[1] http://lists.w3.org/Archives/Public/public-tt/2005Oct/0001.html
[2] http://lists.w3.org/Archives/Public/public-tt/2005Aug/0014.html
[3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0039.html
[4] http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/

> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 6.2.2) Are GPS time coordinates really needed? Their semantics are
> the same as UTC, aren't they? What is the use case?
>
> Response:
>
> The semantics of GPS are distinct from UTC. The primary difference is
> that UTC is adjusted for leap seconds, and may have seconds labeled
> 23:59:60 and may have minutes that are missing the second labeled
> 23:59:59. As of January 1, 1999, GPS - UTC = 13s. The use case for
> GPS involves the fact that GPS is widely used in television broadcast
> in the US for synchronization purposes. For example, the ATSC A/65
> Program and System Information Protocol (PSIP) standard is used to
> transmit television program schedule information via terrestrial
> digital transmission in the US, and PSIP makes use of GPS time
> coordinates to express begin and end times for programming.

OK, that explains it.

But maybe something like this could be added as a note. Not many people 
know what you just wrote. The grammar in 10.3 also doesn't say that 
23:59:60 is illegal for GPS. Without some explanation, you risk that 
programmers will just do "#define GPS UTC" and save themselves some 
coding.

[TTWG Response 2005-10-27]

Normative references to GPS and UTC definitions have been added. In
addition the following note has been added:

"Note: The primary difference between GPS time and UTC time is that
GPS time is not adjusted for leap seconds, while UTC time is adjusted
as follows: UTC = TAI (<emph>Temp Atomique International</emph>) +
<emph>leap seconds accumulated since 1972</emph>. TAI is maintained by
the <emph>Bureau International des Poids et Mesures</emph> (BIPM) in
Sevres, France.  The GPS system time is steered to a Master Clock (MC)
at the US Naval Observatory which is kept within a close but
unspecified tolerance of TAI."

> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.1) Is xml:space necessary? You'll have to have style attributes
> for space handling anyway, so why complicate matters by doing a half
> job in XML?
>
> Response:
>
> We are not sure what is meant by "doing ... [the] job in XML". Our
> understanding is that a compliant XML processor must always "pass all
> characters in a document that are not markup through to the
> application". Our understanding of xml:space is it permits the author
> to express whether the application should use its "default
> white-space processing mode" or should "preserve all white-space".
> Since we have not introduced the full range of whitespace processing
> style properties into DFXP, such as XSL's linefeed-treatment,
> white-space-collapse, white-space-treatment, and
> suppress-at-line-break properties, we instead rely upon use of
> xml:space as an alternative mechanism for specifying authorial
> intention regarding whitespace preservation. Nevertheless, we believe
> it may be useful to re-express the algorithm specifying the meaning
> of xml:space="default" to instead normatively reference the semantics
> of the above mentioned XSL properties.

Having just two keywords (default and preserve) probably doesn't allow 
the author to express everything he wants (such as preserve spaces and 
still allow line breaks, or vice versa). CSS at first also had just 
those two values (called 'normal' and 'pre', resp.). So we expect that 
there will be demand for more values...

xml:space itself is not extensible, because its syntax is defined by 
XML. If white space handling is made more flexible, DFXP will need a 
new attribute. It might be better to drop xml:space and use a 
white-space attribute right away.

But defining xml:space in terms of the features of XSL (or the newer 
ones of CSS[1] currently under development), will at least make 
xml:space=default do something useful in all languages & scripts.

The meaning of xml:space=preserve is currently not defined and should 
also be defined, maybe in a similar way. In particular, does wrapOption 
override xml:space=preserve or the other way round?

In conclusion: using the 'white-space' property from CSS/XSL would be 
better, especially in view of future extensions; if you define 
xml:space as you say you will, the response is acceptable. Don't forget 
to define xml:space=preserve as well!

[1] http://www.w3.org/Style/Group/css3-src/css3-text

[TTWG Response 2005-10-27]

The previous definition of the semantics of xml:space as found in
section 7.2.3 has been changed to the following in order to rely upon
the semantics of XSL-FO which is normatively used by DFXP to define
formatting and layout:

<quote>
The semantics of the value "default" are fixed to mean that when
performing presentation processing of a document instance as described
by 9.3.2 Synchronic Flow Processing, processing must occur as if the
following properties were specified on the affected elements of the
intermediate XSL-FO document:

* suppress-at-line-break="auto"
* linefeed-treatment="treat-as-space"
* white-space-collapse="true"
* white-space-treatment="ignore-if-surrounding-linefeed"

Similarly, the semantics of the value "preserve" are fixed to mean
that when performing presentation processing, processing must occur as
if the following properties were specified on the affected elements of
the intermediate XSL-FO document:

* suppress-at-line-break="retain"
* linefeed-treatment="preserve"
* white-space-collapse="false"
* white-space-treatment="preserve"

When performing other types of processing intended to eventually
result in a visual presentation by means other than those described in
this specification, the semantics of space collapsing and preservation
as described above should be respected. For other types of processing,
the treatment of the xml:space attribute is processor dependent, but
should respect the semantics described above if possible.
</quote>

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.3) Attributes begin, dur and end are on <tt> and on <body>. Are
> they needed on both?
>
> Response:
>
> Distinct timing context is required on <tt> as opposed to <body> in
> order to provide a timing container for <head> and thence to <layout>
> and <region>, the latter of which can be animated.

Regions that may or may not exist at the time some content is available 
for it... sounds like a headache for authors. All the timing info on 
the content, as in SMIL, seems much more manegable.

But we'll take your word for it...

[TTWG Response 2005-10-27]

The timing attributes on <tt> have now been removed, with those on
<body> being used instead.

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.7) Is the <br> needed? You can also use two <p> elements if you
> need two lines.
>
> Response:
>
> In XSL, <fo:block/> does not produce a block area since it has empty
,> content. Since TT AF maps <p/> to <fo:block/> semantics, two empty
> <p/> elements from the TT namespace would map to:
>
> <fo:block/> <fo:block/>
>
> and thus not produce any visible side effect.
>
> In contrast,
>
> <p> <br/> </p>
>
> is defined to produce the same result as
>
> <fo:block> <fo:character character="&#x2028;"
> suppress-at-line-break="retain"/> </fo:block>
>
> We will review if additional clarification is required to express
> these intentions.

The question was why

    <p>First line.<br>
    Second line.</p>

instead of

    <p>First line.</p>
    <p>Second line.</p>

It still seems there is no need for the <br> element, neither to start a 
new line nor to create empty space (the latter can be done with 
padding, e.g.).

But it doesn't matter.

[TTWG Response 2005-10-27]

We believe it is useful to allow an author to express paragraph blocks
independently from forced line breaks within a paragraph block.

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 7.1.7) What happens if you put two <br> elements in a row, do you get
> an empty line or not?
>
> Response:
>
> Given
>
> <p> <br/> <br/> </p>
>
> a compliant presentation processor produces the same results as:
>
> <fo:block> <fo:character character="&#x2028;"
> suppress-at-line-break="retain"/> <fo:character character="&#x2028;"
> suppress-at-line-break="retain"/> </fo:block>

So the intention is that <br> is a hard line break. Fine.

But are you sure that U+2028 produces a line break? It doesn't in CSS. 
(It wasn't explicit before, but in CSS 2.1 it is.)

[TTWG Response 2005-10-27]

It is certainly our intention that <br/> produce a hard line break. We
will investigate XSL FO semantics and make any necessary modifications
to ensure that our intention can be consistently realized according to
XSL FO usage.

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.1.1) What happens if a DFXP document has a style PI? I assume a
> DFXP application will ignore it (just like a generic XML viewer will
> ignore the <styling> elements).
>
> Response:
>
> No normative semantic has been defined for any processing
> instruction; therefore, a compliant presentation processor may
> ignore.

Might be useful to say somewhere that DFXP doesn't use the style PI, but 
it's up to you.

[TTWG Response 2005-10-27]

The following language has been added to the prologue of section 8:

"No normative use of a stylesheet processing instruction is defined by
this specification."

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.10) The note says that a horizontal font-size is useful in
> systems that have two fonts: normal and double-width. But do you
> expect a horizontal font-size to work on any other system? or with
> any other value than "1c" or "2c"?
>
> Response:
>
> We believe that specifying both horizontal and vertical sizes may
> produce a continuously varying anamorphoic transformation on devices
> capable of rasterizing fonts in a rectangular EM square. We do intend
> to mandate that a given compliant presentation processor must support
> either continuous anamorphic scaling of EM square or support some
> discrete set of anamorphically-transformed font sizes.
>
> We also recongize that this feature constitutes an extension not
> presently supported in XSL, and isn't adequately addressed by section
> 9.3.2 sub-items 6 and 7 (pertaining to populating XSL style
> properties). Therefore, we will add additional normative language to
> 8.2.10 that expresses the intended semantics.

We hope that that additional language is easier to understand than this 
response, though :-)

[TTWG Response 2005-10-27]

We will re-review the language of the referenced note and make
additional improvements if warranted.

In addition, the following has been added to the definition of
ttp:cellResolution in 6.2.1:

"Note: The use of a uniform grid is employed only for the purpose of
measuring lengths and expressing coordinates. In particular, it is not
assumed that the presentation of text or the alignment of individual
glyph areas is coordinated with this grid. Such alignment is possible,
but requires the use of a monospaced font and a font size whose EM
square exactly matches the cell size."

Also related, the following has been added to the definition of the
<length> syntactic construct in 8.3.11:

"When specified relative to a font whose size is expressed as a single
length measure or as two length measures of equal length, the unit of
measure em is considered to be identical to that defined by [XSL 1.0],
§ 5.9.13; however, when specified relative to a font whose size is
expressed as two length measures of non-equal lengths, then one em is
equal to the inline progression dimension of the anisomorphically
scaled font when used to specify lengths in the inline progression
direction and equal to the block progression dimension of the scaled
font when used to specify lengths in the block progression direction."

> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.17) "padding" allows one, two or four values. Why not three, as
> in XSL/CSS?
>
> Response:
>
> We did not find the use of three values to be a particularly useful
> feature, and did not need to support the limited subset of TT AF
> expressed by DFXP. It is possible that AFXP will support the larger
> subset.

It's certainly less often used than the others, but if the feature is 
meant to be the same it is good if the syntax is the same, too. It 
makes sharing code and experience easier.

Please consider adding the missing syntax and especially don't make the 
syntax different between DFXP and AFXP.

[TTWG Response 2005-10-27]

We will add the three value form in order to improve interoperability
as suggested.

> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.2.19) "textAlign" doesn't allow values "left" and "right" as in
> XSL/CSS, although it is much easier for an author to write "left"
> than "start" (or "end") when he means "left." Also, when converting
> from/to other formats, it is easier if the value for textAlign in
> DFXP is a direct translation of the corresponding value in the other
> format, rather than a function of that other value and the
> "direction" property.
>
> Response:
>
> We think that when at author writes "left" in a LRTB writing mode,
> that they actually mean "start". We want to encourage the author to
> express their logical intention. We are not certain if there is a
> strong use-case for specifiying non-relative (absolute) text
> alignment.

It's doubtful there is a use-case, even a weak one, for 
context-dependent keywords. Imagine somebody asks you: "How do I 
right-align my text?" You answer: "Simple. textAlign=end." 
Unfortunately, some or all of his text was in Arabic...

The claim that relative keywords are better is based on the assumption 
that style sheets for one script can be re-used for another. It's 
doubtful that that assumption holds, even for trivial style sheets. And 
in the case of DFXP, there isn't even a style sheet; the alignment and 
the text are specified together. Why would you make it difficult for 
somebody who just wants his text on the right?

99.9% of the DFXP documents will be in only one script.

And, in fact, people who write documents with both a ltr and a rtl 
scripts will have an even more difficult time. Not only do they have to 
translate in their mind right/left to start/end, but they will have to 
change that mapping when they change scripts. To right-align an English 
paragraph, they will have to use textAlign=end, but to right-align a 
Hebrew paragraph, they will have to use textAlign=start.

Also, DFXP is meant to be transformed to other formats, depending on the 
software or hardware that actually displays the text. There are dozens 
of timed text formats, but none that support script-relative text 
alignment. So all converters will have to implement a translation from 
start/end to left/right, which is an extra risk of bugs.

You can simulate left and right with start and end, but it is an extra 
hurdle for users. We strongly advice you to add left and right.

[TTWG Response 2005-10-27]

We will add "left" and "right" absolute values to improve
interoperability as suggested.

> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.6) The generic font family names suggest specific kinds of fonts,
> but the spec effectively says to expect nothing. In that case, why
> aren't they called "font1" to "font5"? Some help for implementers
> seems useful. If an implementation has different fonts available, I
> think users would like it if the fonts are mapped somewhat
> intelligently.
>
> Response:
>
> Well it is either implementation dependent or not. We really want the
> former. We prefer to let the market decide whether an implementation
> does something sensible or not. To do something formal would require
> introducing PANOSE concepts or equivalent which doesn't seem
> particularly worthwhile.

There is a middle ground between not specifying anything and specifying 
every last bit. The names clearly suggest that the font families are 
neither arbitrary nor fully specified, but the definition fails to 
follow up on that. Whether the "market" will solve it depends on how 
open that market is. If there is a dominant implementation that fails 
to do something reasonable, then the result is effectively that the 
feature disappears, independent of whether users want it or not.

But we won't insist. Let's just hope that by the time the spec is 
updated the "market" will not have made it impossible to fix this.

[TTWG Response 2005-10-27]

The relevant material in 8.3.6 has been modified to read as follows:

"The mapping between a generic (font) family name and an actual font
is not determined by this specification; however, the distinction of
monospace versus proportional and serif versus sans-serif should be
maintained if possible when performing presentation."

where the clause starting "however, ..." has been added.

>
> *********************************************************************
>**
>
> Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200
>
> 8.3.6) The generic font families are different from those in XSL/CSS.
> Maybe DFXP doesn't need "fantasy" and "cursive," but it could have
> kept
>
> "sans-serif" and "serif" without renaming them. Also, is the
> difference "monospace-sans-serif" vs "monospace-serif" really needed?
> Just one monospace font has been enough for all my uses (which
> weren't subtitles, I admit).
>
> Response:
>
> The TT WG believes there are a number of examples of all combinations
> of {monotype,proportional} x {sans-serif,serif} in use in
> international subtitling applications that justify labeling all
> combinations.

That sounds like a contradiction with the previous issue: it is 
important to distinguish serif monospace from sans-serif monospace, but 
it is not important to define that 'monospace-sans-serif' and 
'monospace-serif' are different (where possible)?

It is a bad idea to use a feature that exists in CSS/XSL (apart from the 
CamelCase) but change the values.

If you are keen on re-use (as your answer to the first issue, on 
namespaces, indicates), then you should not throw away people's 
knowledge so easily. There is no reason to rename sans-serif to 
proportional-sans-serif and serif to proportional-serif.

What to do? Clearly, it is possible to define those keywords, but the 
fact that CSS and DFXP are different for no apparent reason will look 
bad...

[TTWG Response 2005-10-27]

We will retain the following values, now camelCased:

serif
sansSerif
monospace

and introduce only the following extensions:

default
monospaceSerif
monospaceSansSerif

We will further define "monospace" to be arbitrary serifness (as in
CSS), while the new qualified forms are specific. We will use
the existing "serif" and "sansSerif" instead of the proposed replacements:
proportionalSerif and proportionalSansSerif.

***********************************************************************

END

Received on Thursday, 27 October 2005 22:22:05 UTC