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

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 19:32:22 UTC