W3C home > Mailing lists > Public > public-tt@w3.org > March 2005

Coments - last call draft

From: Charles McCathieNevile <charles@sidar.org>
Date: Thu, 31 Mar 2005 11:46:15 +1000
To: public-tt@w3.org
Message-ID: <op.soha7dsrw5l938@researchsft>

1. Meeting requirements


It is intended that a more feature-rich profile, known presently as the  
Authoring Format Exchange Profile (AFXP), be developed and published to  
address the full set of documented requirements.


Is there any concrete reason to believe this will take place? The group  
has had its charter extended already, just to produce this restricted  
draft. Is the group working on this more complete version already? Or is  
this just a hope?

2. Validity

in section 4 on Document Types is

The definition of validity employed here does not require the presence of  
any attribute, does not take into account the value of any attribute, and  
does not take into account any semantics associated with ID/IDREF/IDREFS  
typed attributes.

Why not? Attributes are defined all over the spec, so I would have thought  
they are important.

3. Default length units

Section 6.2.3 defining defaultLengthUnit says

If not specified, the default length unit must be considered to be pixels.

For accessibility reasons, it seems better in a pure text format to use an  
element based on font size, such as the em unit, as a default. I realise  
this implies a small change in the practice of authors, who are probably  
generally accustomed to working in pixels. But then they are probably not  
generally accustomed to working on accessibility.

4. frameRateMultiplier

It is hard to decipher this section. In particular, please explain where  
the numbers come from. It seems that this is designed to default to NTSC,  
which as I understand it is a relatively parochial approach since it is  
widely used only in North America. If the defaults for other systems such  
as PAL or SECAM are different, it would seem reasonable to include a  
systemType attribute which determines the default.

Actually it seems strange that so much of this is in the spec. I  
understand that it enables synchronisation with traditional television,  
but it seems a lot of complexity.

5. Duration and begin/end

It would be helpful if the spec said what happens when the begin/end and  
the dur attributes don't agree.

6. Compulsory xml:lang attribute

Cool idea.

7. Style, and user styling

Quite a lot of work went into CSS. It is also considered pretty normal to  
style XML with CSS.

For accessibility purposes it is helpful to have something like the CSS2  
Cascade rules (which represented a change from CSS1 for enhanced  
accessibility). It turns out that text is about the only area where it is  
easy for user styles to make sense, so it seems a shame that there is no  
mechanism anticipated by the spec for using CSS and takng advantage of the  
cascading of rules that are important to the user, where appropriate.

8. Timed text and sign language

For people who are deaf and use sign language, it is often very much more  
appropriate to have sign language than text as the captioning format. It  
seems that there are already a number of video formats, and one might  
expect one of them or an SVG animation to be used in the cntext of a SMIL  
presentation. It might be worth noting within the spec that this use case  
effectively fals outside the scope, not because the spec ignores the need  
but because it is best satisfied by using this spec for its intended  
purpose (timed text) within the context of a group of specifications for  
timed multimedia.

(In other words, this could be done with a brief note in the introduction  
or somewhere).



Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org
Received on Thursday, 31 March 2005 01:46:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:01 UTC