Re[2]: updated timed-text document

On Tuesday, 12 March, 2002, 20:36:16, Dave wrote:

DS> At 10:45 -0500 3/11/02, geoff freed wrote:
>>Everyone:
>>
>>The timed-text requirements document has been updated; the new 
>>version is available at
>>
>>http://www.w3.org/AudioVideo/timetext.html
>>

DS> Hi Geoff, some brief comments:

DS> a) I'm not sure what the opposition to fonts is;  what we said in 
DS> 3GPP was that the font request was a comma-separated list of 
DS> "suggestions", which might include the "meta-names" serif, 
DS> sans-serif, and monospace.

Why would you use a different mechanism to the CSS2 font mechanism,
which - as you say - gives a list of fonts which are tried in order
and then at the end, a genericv font family (serif, etc) which is not
a real font name but is a hint, any suitable font can be used, as a
last attempt to present the characters in soomething like the desired
style, before falling off the end of the list and using *any* font the
implementation wishes (which may include displaying some characters as
the "missing glyph"..

DS>  The interaction of fonts, styles, and 
DS> character sets needs careful exploration.

With respect, it does not need careful exploration. There are already
well understood mechanisms for how styling applies fonts to a wide
range of characters and how character sets 9used for encoding a
document in transit) relate to the universal character set (Unicode)
which is the conceptual basis on which W3C specifications are built
(eg in XML, a numeric character reference always refers to the Unicode
code point, never to a byte value in the current encoding).

DS> b) I'm not sure what point (2) "usable in all character sets" means? 
DS> Does this mean "allow all Unicode characters"?

I hope that what it means is that Unicode is the conceptual basis,
that other encoding can be used but might not be supported by all
applications, and that (since this format will have an XML
representation) UTF-8 and UTF-16 are supported by all implementations
(as required by XML 1.0).

DS> c) 3 says to have a default Unicode font, but Unicode isn't a font at 
DS> all.  I'm a little lost here.

I think this requirement, taken together with the preceding one are
trying to express different aspects of the same thing and should be
coalesced. You are quite correct that fonts, already addressed in
requirement I1, are orthogonal to the issue.


DS> d) Adding the URL <http://www.w3.org/TR/ruby> to point 5 would help.

Yes. It would also help if it is made explicit that this markup will
be used to add Ruby support, (unless the intention is to design
different markup, in which case some justification should be
provided).

DS> e) Point 6 should say "markup OF the language", i.e. identify the 
DS> language the text is in.  This is needed for text-to-speech, sorting, 
DS> and various other operations.

Yes, agreed.

DS> f) 9 asks for motion, right, and IV.1 says no motion.  I'd say that 
DS> "marquee" and "credits" are both pretty key requirements.

DS> g) 10 appears to be asking for custom or non unicode glyphs.  I guess 
DS> a major question is whether we use only Unicode as an encoding 
DS> standard.

Unicode is not an encoding standard (though UTF-8 and UTF-16 are
encodings of Unicode). Unicode is a universal character repertoire and
ordering. Once this point is clear, issues of encoding can be cleanly
separated from the basic architecture. Once that is done, there are
two possibilities for representing characters not in Unnicode a) the
unicode private use area b) the altglyph mechanism, where a font
contains glyphs that are not associated with any Unicode code point,
but only indirectly (such as by direct id reference, by complex glyph
substitution mechanisms for certain languages such as the north indic
languages, etc).

DS> h) III.2 should probably say "Have a valid XML representation" as we 
DS> may want to permit compact binary format(s) (e.g. in an RTP packet) 
DS> as well.

I think there are several possibilities, some which this point might
be trying to say:

a) there will be an XML representation of the timed text format (since
   markup is mentioned, this is pretty much a given)
b) the XML will be well formed (otherwise it is not XML)
c) the XML will be valid to a DTD
d) the XML will be valid to a W3C XML Schema
e) the XML will meet some other validity constraint mentioned in the
   prose of the specification
f) XML will be the only representation of this format
g) XML will be the canonical representation of this format, but
   transcoding to binary XML representations is allowed for particular
   devices
h) there will be a single defined binary representation as well as the
   XML representation
i) there will be many representations, XML is just an example

My recommendation would be to select a, b, d, g and consider h and avoid i

DS> In general, the document desperately needs a paragraph or two on the 
DS> usage modes and expected needs, for example:

DS> sub-titling
DS> karaoke
DS> credits
DS> ticker tapes
DS> closed captioning
DS> text overlay
DS> hyperlinks and interactivity
DS> type-in (user-edited text)???

I agree that some initial expository material justifying why this
format is needed and what its intended usage would be, would be a
great help once this document comes under wider review.


-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 13 March 2002 07:40:12 UTC