DFXP LC Comments - Issue 10 Response; Bert Bos

Dear Bert,
	
Thank you for your comments, [1], on the DFXP Last Call
Working Draft. The TT WG has concluded its review of your comments and
has agreed upon the following responses.

If you require any further follow-up, then please do so no later than
September 1, and please forward your follow-up to <public-tt@w3.org>.

Regards,
Glenn Adams
Chair, Timed Text Working Group

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

Citations:

[1] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0039.html

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

5.1) Why six different namespaces in one document format? It doesn't
seem like you can use any of them on its own.

Response:

In the context of TT AF, the division of namespaces is intended to
provide distinct name spaces in order to avoid collisions and to
provide functional context for a name. In this context, these
namespaces are designed to interoperate. In a more general context,
one could make use of the same namespaces in other contexts outside of
DFXP. There is no technical issue here.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

5.2) If it is important for an implementation to know the profile a
document conforms to, shouldn't the profile name be passed out of band
(as a MIME type parameter), instead of inside the document? A profile
is usually something you author to, but then neither the client nor
the server need to know that you do so; or it is something a client
uses for content negotiation (e.g., HTTP Accept header or TYPE
attribute on an HTML LINK element). It is not useful inside the
document, except perhaps for the Unix "file" command...

Response:

A "profile" or "version" could be passed out-of-band, but since DFXP
does not define a transport mechanism, such definition is more
appropriately defined in another specification in order to suit the
needs of that specification.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

5.2) In fact, the spec doesn't say what an implementation does with
profiles. I assume it doesn't do anything with it (unless perhaps if
the program is a validator).

Response:

DFXP explicitly does not specify a schema binding mechanism.
Conformance clause 3.2 sub-item 1 places this responsibility on a TT
AF Content Processor. Nevertheless, we recognize that some guidance be
provided to processor implementers; therefore, we will add informative
language suggesting that a processor may make use of the ttp:profile
parameter as a means for identifying the declared language subset
(profile).

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

5.3.1) Why lowerCamelCase even for names that are borrowed from other
specifications? XML names can contain dashes.

Response:

The TT WG has adopted a consistent convention for all names, and will
provide an informative annex indicating heritage of tokens and names,
indicating whether they had camel case normalization applied.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.1) EDITORIAL: s/express number/express the number/

Response:

Will fix.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.1 until 6.2.13) All (not sure about one or two) of these
attributes can only occur on one element, viz., <tt>. So why are they
defined as global attributes (with a prefix)?

Response:

It is expected that these attributes may be used in different contexts
in AFXP; it is also possible that some of these may be useful in other
host languages that may choose to adopt features from TT AF.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.2) Where is the syntax of GPS time coordinates defined? I couldn't
find the definition in the spec and there is no reference either.

Response:

The phrase "time expressions" is formally defined in section 10.3. A
cross-reference will be added to make it clear that all time
expressions, whether GPS or not, make use of a consistent syntax. An
appropriate reference will also be added to permit semantic
interpretation of time expressions in the GPS time space.

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

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.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.2) It seems that there may be only one clockMode attribute per
document (if I interpret the note at the end of 6.2.13 correctly), but
unlike for the other attributes, there is no paragraph in this section
that says that clockMode may only occur on the <tt> element.

Response:

This was an oversight. An appropriate constraint will be added to be
constent with other time related attributes.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.3) Is the defaultLengthUnit attribute needed? In CSS, we found it
useful to have unitless numbers mean something specific, different
from a length, e.g., as a multiplier. That possibility is removed when
there is a default unit. Also, in a typical document there probably
aren't more than a dozen or so length values, so declaring a default
doesn't actually make the document shorter.

Response:

After careful consideration, the TT WG has agreed to remove both the
ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and
instead require lengths and offet times to specify an explicit metric.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.3) The default is "pixels," but are they device pixels or px
units, as in XSL/CSS?

Response:

No longer applicable due to removal of ttp:defaultLengthUnit; however,
the larger question of what does "px" mean when specified in a length
will be addressed by adding language indicating that the XSL
definition applies.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.4) Same question: is defaultTimeMetric necessary?

Response:

After careful consideration, the TT WG has agreed to remove both the
ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and
instead require lengths and offet times to specify an explicit metric.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.5) EDITORIAL: s/of document instance/of a document instance/

Response:

Will fix.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.6) Is NTSC the only case where a frameRateMultiplier is necessary?
If so, then maybe a single keyword ("NTSC" on the frameRate attribute)
is enough, and a general multiplier is overkill.

Response:

NTSC is not the only case; furthermore, there are a variety of
operational usages in studios and in broadcast where
frameRateMultiplier may effectively be a continuous function. Use of
an enumeration would be overly restrictive and require constant
updating.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

6.2.6) EDITORIAL: s/MHz/Hz/ for the first occurrence in the note.

Response:

Will fix.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

7.1.1) Why must xml:lang be specified? Isn't omitting it the same as
defining it to be the empty string?

Response:

The goal is to strongly encourage authors and authoring systems to be
explicit about language. Specifying xml:space="" is not the same as
not specifying xml:space. The former is an explicit authorial
expression of "no default language"; the latter leaves authorial
intention unexpressed. We wish to enforce some intentional expression
even if it is "no default language".

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

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.

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

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.

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

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.

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

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>

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

7.1.7) Why does the <br> element have an xml:space attribute? Empty
elements don't contain spaces...

Response:

It was specified for symmetry sake (in order to be uniform on all
content elements). We will add an informative note that indicates that
it is effectively ignored if specified.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

7.2.3) Rule three seems to imply that the mark-up

    <p>one<span> two </span>three</p>

is displayed as "onetwothree" without any spaces. Maybe you meant to
omit leading and trailing spaces from the <p> element only?

Response:

Based on a comment above, 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. We will eiother re-express thus or correct the algorithm
(which we copied from SVG).

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

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.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.1) The bullet list of elements that accept style attributes should
be non-normative (i.e., a note), because that information is already
known from earlier sections.

Response:

We believe there is no inconsistency in presenting the same normative
requirements twice, given the different contexts of the specification,
provided that there is no inconsistency between the requirements. We
believe there is no inconsistency at this time.

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

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.


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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.16) The note says that a <p> is displayed on one line, unless a
<br> is used. But doesn't that also depend on wrapOption?

Response:

Good catch. Will fix.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.16) overflow in CSS/XSL has a value "scroll" but here it is
renamed to "dynamic." Why? An automatic scroll, such as the marquee
effect of "dynamicFlow," is a valid "scrolling mechanism" in XSL/CSS
terms.

Response:

We weren't certain if we could define "scroll" to mean "apply the
dynamic flow semantics defined in DFXP"; but given that you suggest
this we will change to using "scroll" and define "scroll" semantics
according to the dynamic flow features.

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

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.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.18) "showBackground" appears to be similar to 'empty-cells' in
CSS.  Is there no way to merge them?

Response:

Perhaps, but we feel comfortable basing the usage in DFXP on the
current SMIL attribute whose name is "showBackground" [1].

[1]
http://www.w3.org/TR/2005/REC-SMIL2-20050107/layout.html#adef-showBackgr
ound

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

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.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.20) CSS3 proposes a 'font-effect: outline' property to create
outline fonts, but it doesn't give control over the thickness of the
outline, let alone the amount of blur. Isn't 'font-effect: outline'
enough?

Response:

A number of TT WG members have a strong preference for providing the
ability to specify blur radius. There has been a request for
expressing separately the inner and outer color of the blur and
possibly gradient parameters to apply at the transition boudnary; we
chose a simple compromise that was modeled closely on the text-shadow
property of CSS2.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.2.22) The example is supposed to show that "visibility" can hide
text, but there is no text to hide... The first text only appears
after 1 second.

Response:

As it turns out, (1) the intent of this example was not "to show that
'visibility' can hide text", and (2) there is a bug in the example, in
that tts:visibility="false" on the paragraph means the paragraph (and
its children) will never be visible. The example DFXP document should
have read:

<p region="r1" dur="4"> <span tts:visibility="hidden"> <set begin="1"
tts:visibility="visible"/> Curiouser </span> <span
tts:visibility="hidden"> <set begin="2" tts:visibility="visible"/> and
</span> <span tts:visibility="hidden"> <set begin="3"
tts:visibility="visible"/> curiouser!  </span> </p>

We will fix.

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

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.

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

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.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.3.11) The units px, em and c are defined syntactically, but what do
they mean? I assume px is as in XSL/CSS and em is the font-size,
because 8.2.10 mentions an "EM square" in relation to font-size. "c"
is probably the cell as defined by 6.2.1 cellResolution.

Response:

We will add a cross-reference to XSL definitions and expand further on
the definition of "c". But see more below on "em".

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

8.3.11) Is the em unit the vertical font size or the horizontal one?
Or does that depend on whether the length is used to measure something
horizontal or vertical?

Response:

We will elaborate that "em" in the context of a font that expresses an
anamorphic size has two interpretations depending on the context of
usage, i.e., depending on whether the length is being used to express
a distance along the block or inline progression dimensions.

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

Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200

10.1.2) begin, end and dur attributes: what happens if they conflict?

Response:

At present, section 10.4 normatively references the semantics of SMIL
2 for the purpose of interpreting these attributes, as well as dealing
with possible conflicts (over-constraint scenarios).  We are
considering fully inlining the timing interval semantics into the
spec, which is a greatly reduced subset of SMIL 2 timing semantics; if
we do this, then the usage and constraints on these attributes will be
fully articulated.

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

Received on Friday, 12 August 2005 19:50:43 UTC