[tt-af-1-0-req] Some (late) comments on the requirements

I started writing my comments a long time ago, but never finished
them. They are still not finished, but better that I send you
something incomplete than nothing at all.

Based on:

    http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915

* 1.2 System model

How about a model of the timed text itself? processing, timing,
structure.

* S0000

What does captioning need, precisely? Color, fonts, font size,
indents, bullets, images, positioning, timing, font styles,
underlining, blinking, text shadow, background, transparency,
sections/groups, repeating blocks, tabulation, right alignment,
centering, vertical text, real-time authoring...

* S001

Ditto

* S002

Probably needs speech generation support, such as CSS audio properties
or another transformation to SSML.

* S003

Is this also intended to be usable to do "marquee" in HTML (embedded
in an OBJECT or IMG element)?

* R100

What is meant by "authored using XSL"? Does that mean the TT AF can be
the result of a transformation from some other XML format? In that
case, why insist on XSL, why not Perl, e.g.?

* R101 - R103

One hopes that the TT AF is simple enough to not need modules or
optional parts...

* R106

This seems to say that the TT AF should not contain functions that
serve no purpose, but it says it in a rather verbose way. Unless I misunderstand, this seems rather obvious...

* R110

What is an "idealized" streamable format?

* R112

The task of the TT WG is to define a TT AF (and probably a TT
format), not to define the editor to write that format with. (Unless you make a case why you need to do this, and probably update the group's charter as well.)

* R204

This requirement only restricts the element and attribute names of the
TT AF to ASCII, since R100 (use of XML) already ensured that all text
content can be written in ASCII. So why not say explicitly that this item is about element and attribute names?

* R209

This makes sense, but some motivation would be good. How about
headings and lists?

* R217, R218

"Embedded" means "in the same file"? Such as a data URL? Or is it an
external image intended to be displayed simultaneously, while
"non-embedded" means "intended as hyperlink"?

If the former, is it also permitted to have the TT AF and the image
together in a file of a third type, such as a "jar" file? If so, is it
OK if that third format is a generic archive format, or should it have
a MIME type that indicates that this is an archive used as TT AF
(though structurally equal to a generic format)?

* R219, R220

Not by inventing a new font format, I hope...

Any idea yet whether there will be a one or more required font formats
(TrueType, SVG) or is it OK when a UA supports at least one font
format, even if it is the only UA to know that format?

* R221

The sentence is hard to read or maybe even ambiguous. What does
"appropriate domain of discourse" mean? Is it a modifier of "text
content" or of "descriptive information"? Is the idea that
you can embed a TEI file in the TT AF?

* R222

This sounds rather ambitious. I thought TT was a mono-media component,
to be used, e.g., inside SMIL, not a SMIL-replacement.

* R223

What does "non-embedded" mean? Does it mean that there is no link to
the audio in the TT AF itself, but the link is somehow somewhere else
(such as in a style sheet)? Or, which is maybe the same thing, that
the TT AF only expresses that there is to be audio of a certain kind
(e.g., via high-level keywords, such as "alert," "warning" and
"error"), without pointing to actual sound files?

* R292, R293

No objection to using XLink, XML Schemas or Relax NG, but why is it a
*requirement* to use them? Why not just an intention? What breaks if
you use something else?

* R300

R301 seems to be a more precise statement of R300. It seems that R300
can be removed.

* R301

Why do you need attributes on elements for the TT AF? Attributes seem
redundant, when you also have external styles and even physically
embedded styles. There is nothing you can do with attributes that you
cannot also do with style sheets, but style sheets can do more. 

The two reasons I can think of for allowing attributes are (1) ease of
hand authoring for quick & dirty projects (a rather weak argument) and
(2) ease of processing, since no memory is required to store style
sheets (but that doesn't hold here, because style sheets have to be
supported anyway).

Maybe this was intended as a requirement for the TT DF instead?

* R305

It might be good to refer to SSML and the upcoming CSS speech module,
since the aural properties of CSS2 will be deprecated (in CSS 2.1) and
there will be a new set of properties in CSS3, compatible with SSML.
They should be very similar to the old ones, but not exactly the same.

* R307

Not sure if I interpret this correctly. Is this like scrolling text,
like a "marquee"?

* R390

See R301. It seems to me that hard-coded styles should be avoided
where possible and only allowed in final-form formats, like a TT DF.
(The principle of separation of structure and style is a relative
principle, but it seems to me that it should hold for the TT AF.)

* R391

It's a good principle to use existing names and definitions where
possible, but don't deprive yourself of the possibility to use names
that fit better with the particular model or syntax that you develop.

[Sorry, that's as far as I got]



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 Thursday, 15 January 2004 14:09:53 UTC