Re: DFXP LC Comments - Issues 2, 5 Draft Responses; Charles McCathieNevile

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