Re: More comments on updated timed-text document

Hi, Chris:

Sorry for the delay in responding; I've been out of town and am just now catching up.

>The grouping in terms of Display, Timing, and Architecture is a good
>one but should Architecture not be presented first?
>
>Also, points I.2 and I.3 (see my previous message) belong more clearly
>under architecture than Display.

I'll re-order the categories (as well as some of the items you and Erik have mentioned elsewhere).

>I.4 is open to misinterpretation as there are special Unicode
>characters that function as bidi overrides. I suspect that this point
>is not calling for their use (markup, instead, should be used) but
>rather, saying that the display of bidirectional text must be
>supported. Which, for a single level of embedding, such as some rtl
>characters in the middle ofd a string of ltr characters, is
>accomplished merely by the existence of such characters. Explicit
>markup is only required to support multiple levels of embedding (ltr
>string nested inside rtl string nested inside ltr string). Is that
>correct?

Yes, exactly.  Thanks for the carification.

>I.6 Expresses both a requirement and a solution, but presents it as an
>example implying that there are a multitude of possible ways to do the
>same thing... I suggest
>rewording as "Allow the language of the text to be identified and text
>in different languages to be appropriately styled, using xml:lang".

>This is another requirement that might be better moved to
>Architecture. In that case, it could be split - this part in
>Architecture:
>"Allow the language of the text to be identified using xml:lang"
>this in Display:
>"Allow text in different languages to be appropriately styled"

I'll split this into two parts as you describe.

>I.10 can be read in several ways.
>
>a) small graphics can be mixed in with the text, the author having
>complete control over the content and form of the graphic and the set
>being open ended.
>...

a) is what i had in mind-- that an open-ended set be available.  masahiko kaneko from microsoft may also have something to add to this, as he and i have discussed this elsewhere (masahiko?)

>It was not clear to me what I.11 means - does this refer to user
>preferences as expressed, for example, through a CSS user
>stylesheet?

I.11 points out user-agent accessibility as specified by the WAI/UA guidelines-- the user needs to have the final say over how the information is presented.  a user stylesheet is one way; a set of UA preferences is another, although I suspect the latter won't necessarily be covered by the ttf document.

>I understand what point II.2 is getting at, but speaking of 'erasure'
>is problematic unless it is assumed that all text will be displayed
>against its own rectangular, opaque background... Between their start and end
>times, they are visible. Thus, having an old caption disappear and no
>new caption displayed simply arises as a natural consequence of the
>architecture.  Thuis would help simplify and define buth II.1
>and II.2

I agree, except (as Erik points out separately) we have to figure out what to do in real-time situations, where text is fed live to the user, and specific non-display intervals are unavailable.

>II.3 and II.4 could be read as contradicting one another on first
>reading. I suspect that II.3 means that in the markup, the text and
>its associated timing should be closely associated so that content can
>be easily re-purposed and easily understood. I suspect that II.4 means
>that in the specification, the markup for text and the markup for
>timing will be defined in separate modules, for example to allow a
>non-timed text format or a timed-something-else format to be developed
>by others, re-using these modules.
>

II.3 is what I initially had in mind, but the point you raise about II.4 is valid and should be included. 

>Point III.6 seems to call for indexability, in other words to be able
>to start a timed presentation at any point in the timeline (seek to a
>point in the timeline; start subtitles half way through a film). I
>agree, and note that SMIL can do this.
>

Not just indexability, but the capability to tune into a live, untimed presentation-- news event, sports, etc.-- and be able to receive the text properly synchronized with the video/audio


>III.7 seems to call for multiple language text only one branch of
>which is displayed (such as the users preferred language) and II.8 for
>multiple language text all of which is presented, such as a quotation
>in one language in the middle of text of a different language. I agre
>with both requirements, but III.8 seems to follow as a natural
>consequence of I.2,I.3 and I.6. This might be more apparent if, as
>suggested, those three are moved to section III Architecture.
>

Agreed.  I'll move this around.


>Its not clear to me what III.10 would mean in practice.
>

Erik Hodge originally proposed this.  I think he means that authors should be able to keep users from downloading the text stream, similar to how users can be prevented from downloading .RM files.  How this can be accomplished, I don't know.  Erik? 

>II.13 suggests two methods, one of which is purely presentational, the
>other of which is more 'semantic' in that it creates named actors or
>roles. This seems to me to be far preferable. It gives more flexibility
>in styling and user choice (see I.11) and enhances re-use and aids
>requirements such as II.14. (by having something clear in the markup
>which tools such as XSL-T can use to create derived forms).
>

The latter is the approach I favor, as well.  I'll clarify this item in the doc.

>In I.16, of the three W3C Recommendations listed as possibilities for
>"complex font displays", only SVG provides this capability. MathML
>describes equations, but does not provide any font display mechanism
>and XHTML does not provide any display mechanism at all.  This
>requirenmet could do with clarification as to what it actually
>means:
>
>a) Display of equations must be supported
>
>b) There is a need for fonts with complex glyphs such as mathematical
>symbols, multilingual characters, closed-captioning specific symbols,
>etc.
>
>c) something else that I didn't understand ....

a) and b) cover it.  I'll clarify this, too.
>
>II.19 is a good requirement. I suggest adding other W3C
>Recommendations that will be used as a basis, such as XML 1.0, CSS2,
>SVG 1.0 and so on (although, depending on the timescale envisaged, SVG
>1.1 might be more appropriate particularly given the recent 3GPP
>decisions to make SVG Tiny a mandatory part of MMS, SVG Basic an
>optional part, to use SMIL Basic, etc).
>

Okay.

>As already noted by Dave Singer, IV.1 contradicts I.9 and perhaps I.12
>and I.14. In addition, given III.19 it seems like an unnecessary
>restriction, as SMIL already gives a means to give motion to text, and
>SVG uses such facility extensively.
>

If no objections from others, I'll remove this from the list.

>A very good requirements document, Geoff, it was a pleasure to
>review it.
>
>Question - what is the visibility of this document, is it member-only
>or public?

I don't have a problem with making it available to others-- Al, any objections at this point?  Now is a good time since we want to get all the input we can.  Chris, let me make the updates before you distribute the url.  I should be able to have a new version available by the end of March 19.  I'll send a note to the list when it's available.

Thanks for your comments!
Geoff/WGBH

Received on Monday, 18 March 2002 12:26:45 UTC