- From: Bert Bos <bert@w3.org>
- Date: Fri, 22 Apr 2005 20:44:52 +0200
- To: public-tt@w3.org
Hello TT WG,
Thanks for permitting a delay. Here are the promised comments:
5.1) Why six different namespaces in one document format? It doesn't
seem like you can use any of them on its own.
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...
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).
5.3.1) Why lowerCamelCase even for names that are borrowed from other
specifications? XML names can contain dashes.
6.2.1) EDITORIAL: s/express number/express the number/
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)?
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.
6.2.2) Are GPS time coordinates really needed? Their semantics are the
same as UTC, aren't they? What is the use case?
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.
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.
6.2.3) The default is "pixels," but are they device pixels or px units,
as in XSL/CSS?
6.2.4) Same question: is defaultTimeMetric necessary?
6.2.5) EDITORIAL: s/of document instance/of a document instance/
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.
6.2.6) EDITORIAL: s/MHz/Hz/ for the first occurrence in the note.
7.1.1) Why must xml:lang be specified? Isn't omitting it the same as
defining it to be the empty string?
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?
7.1.3) Attributes begin, dur and end are on <tt> and on <body>. Are they
needed on both?
7.1.7) Is the <br> needed? You can also use two <p> elements if you need
two lines.
7.1.7) What happens if you put two <br> elements in a row, do you get an
empty line or not?
7.1.7) Why does the <br> element have an xml:space attribute? Empty
elements don't contain spaces...
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?
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).
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.
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"?
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?
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.
8.2.17) "padding" allows one, two or four values. Why not three, as in
XSL/CSS?
8.2.18) "showBackground" appears to be similar to 'empty-cells' in CSS.
Is there no way to merge them?
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.
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?
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.
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.
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).
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.
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?
10.1.2) begin, end and dur attributes: what happens if they conflict?
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Friday, 22 April 2005 18:45:00 UTC