- From: Charles McCathieNevile <charles@sidar.org>
- Date: Thu, 31 Mar 2005 11:46:15 +1000
- To: public-tt@w3.org
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). cheers Chaals -- 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