- From: Thierry MICHEL <tmichel@w3.org>
- Date: Sat, 13 Aug 2005 00:31:17 +0200
- To: "Glenn A. Adams" <gadams@xfsi.com>
- CC: Charles McCathieNevile <charles@sidar.org>, W3C Public TTWG <public-tt@w3.org>
Charles, If you require any further follow-up please do so, and if you are satisfied with the TTWG response, please acknowledge it by replying to this mail and copying the TTWG public mailing list: public-tt@w3.org Regards, Thierry Michel Glenn A. Adams a écrit : >Dear Charles, > >Thank you for your comments, [1] and [2], on the DFXP Last Call Working >Draft. The TT WG has concluded its review of your comments and has >agreed upon the following responses. > >If you require any further follow-up, then please do so no later than >September 1, and please forward your follow-up to <public-tt@w3.org>. > >Regards, >Glenn Adams >Chair, Timed Text Working Group > >************************************************************************ > >Citations: > >[1] http://lists.w3.org/Archives/Public/public-tt/2005Mar/0076.html >[2] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0011.html > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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? > >Response: > >Although producing an AFXP specification has remained a goal of the >TT WG, it is unclear if there will remain sufficient time in the >current charter as well as continued commitment of resources by >participants to accomplish this. The TT WG invites your feedback and >assistance in helping achieve this goal. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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. > >Response: > >Will change 3.1 item (4) to read "The Reduced XML Infoset satisfies >all mandatory constraints defined by this specification." Also, will >remove 1st note in Section 4 "The definition of validity ...". > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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. > >Response: > >Due to other comments, the ttp:defaultLengthUnit attribute will be >removed. An author must now explicitly specify units for all length >expressions. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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. > >Response: > >We will add an informative reference to SMPTE 170M specification which >can provide more background for persons unfamiliar with video coding >standards. The information in 6.2.6 regarding NTSC is merely exemplary >(in a note), and does not constitute a default. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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. > >Response: > >At present, section 10.4 normatively references SMIL semantics for >interpreting timing attributes, including begin, dur, end; however, >the TT WG is considering whether to rewrite 10.4 to directly specify >semantics of time interval computation, in which case, DFXP would >include full definitions of use of begin, dur, and end. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >6. Compulsory xml:lang attribute > >Cool idea. > >Response: > >Thank you. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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. > >Response: > >An informative reference to the User Agent Accessibility Guidelines >(UAAG) will be added to DFXP, referring UA implementers to consider >those guidelines. > >************************************************************************ > >Comment - Issue #2 [1]; 31 Mar 2005 11:46:15 +1000 > >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). > >Response: > >Good suggestion. We will add a note in the introduction to this >effect. > >************************************************************************ > >Comment - Issue #5 [2]; 03 Apr 2005 16:17:28 +1000 > >On Sat, 02 Apr 2005 00:06:17 +1000, Al Gilman ><Alfred.S.Gilman@ieee.org> wrote: > > > >>>On the other hand accessibility issues are not addressed by FO. It >>> >>> >is >> not at all clear how a user should expect to provide styling >rules to >> meet their particular needs, as is trivial using CSS for >text styling. > > > >>On the one hand, XSL FO does address accessibility through the > >> >> >link-to-source provision. > > > >>http://www.w3.org/TR/xsl/slice7.html#common-accessibility-properties >> >> > >This is for XSL FO documents - not for a different collection that >happens to use some of the properties out of XSL-FO. A link to the >source where it is some other format isn't likely to be any more >helpful than the DFXP document. > > > >>If DXFP does not emulate this, it should be considered. >> >> > > > >>On the other hand, CSS already arogates to itself the ability to > >> >> >supercede presentation properties asserted inline in the source being > > >>styled. >> >> > >Right. My contention is that DFXP should use CSS as the mechanism by >whch User Agents provide users with the ability to override >presentation, where that is required for accessibility reasons in the >case that DFXP is served directly. > >Response: > >An informative reference to the User Agent Accessibility Guidelines >(UAAG) will be added to DFXP, referring UA implementers to consider >those guidelines. > >************************************************************************ > > > >
Received on Friday, 12 August 2005 22:31:41 UTC