Re: Coments - last call draft

On Fri, 01 Apr 2005 00:54:41 +1000, Glenn A. Adams <gadams@xfsi.com> wrote:

> Thanks much for your comments. Following are some personal
> replies/comments. The TT WG will follow up with a consensus response.
>
>> -----Original Message-----
>> From: Charles McCathieNevile [mailto:charles@sidar.org]
>> Subject: Coments - last call draft
>>
>> 2. Validity
>
> Good catch. I had copied this language from another document and
> neglected to fine tune it for DFXP purposes. I expect this will be
> resolved by adding normative conformance requirements on certain
> attribute usage and semantics.

OK.

>> 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.
>
> All of the legacy distribution formats with which DFXP was designed to
> interoperate are based on pixel units as the default (and only) units.
> We expanded DFXP to support additional units, but made pixels the
> default for compatibility with these legacy formats.

Sigh. I'll think about this some more. I am not surprised by this. But I  
am not sure that px are a good choice even given this situation.

>> 4. frameRateMultiplier
>>
>
> I agree this is somewhat hard to decipher, particularly if you have no
> background in Television Engineering. Nevertheless, these parameters are
> essential information needed to communicate sufficient information to
> convert between a frame based temporal coordinate space (like SMPTE 12M)
> and a real-time or media time temporal coordinate space.

Yep.

> Regarding the default, NTSC is not defined as a default. The default
> frameRateMultiplier is defined as 1:1. The discussion of NTSC is an
> example of a frame rate which is (30 * 1000/1001). Do you think it is
> necessary to add another example that discusses another regional usage
> (such as PAL, where the frame rate is exactly 25, with multiplier
> remaining at the default 1:1)?

No, just anticipate that many people will stop reading at this point. It  
might seriously be worthwhile giving a rough guide and then the detail for  
this section, so people realise taht what comes after isn't such  
specialised gobbledygook.

>> 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.
>
> The most important use case for TT is related to its interoperation with
> video media, thus it cannot be avoided. In fact, one way to look at this
> is that it introduces into the W3C a more sophisticated formalization of
> certain video related timing aspects (which were not formally addressed
> in SMIL).

Fair enough.

>> 5. Duration and begin/end
>> 6. Compulsory xml:lang attribute

OK, consider me satisfied.

>> 7. Style, and user styling
>>
>> Quite a lot of work went into CSS. It is also considered pretty normal
>> to style XML with CSS.
>
> Quite a lot of work went into XSL FO as well, which, in turn, is based
> on many CSS style properties.
>
> The WG decided fairly early to adopt XSL FO as our basic
> layout/formatting model, partly because it addresses I18N issues better
> than CSS2, and we didn't want to be delayed waiting on the finalization
> of CSS3 in which I18N issues have been addressed. We also wanted to make
> use of a strict XML encoding of style information to enable
> transformations (I personally view this as a major negative for CSS in
> an XML world.)

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.

>> 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.
>
> In general, the WG has tried assiduously to avoid defining UA behavior.

In this case I think it is a mistake. There are some cases where it makes  
sense to describe what User Agents MUST, SHOULD and MAY do, and this case  
might be one of them (since otherwise it maynoteven get onto the radar  
ofmany developers, leading to a serious lack of accessibility in practice).

>> 8. Timed text and sign language
>>
> Conceptually, there is certainly a relation between a signed media
> object and a caption/subtitle media object, both of which are
> alternative representations of information typically encoded in an audio
> media object for hearing users. The focus of the TT WG has been on
> defining a TT media object. Perhaps the SVG WG might be interested in
> evaluating a specialized usage of SVG that would support a sign language
> media object.

Hmmm. I am not sure if it would be an SVG object or a real video more  
often. Anyway, it is possible to put this stuff in with SMIL without too  
much hassle (although the mechanism involves switching on languages and I  
am not sure how well that is handled in the muliple language case).

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

OK.

cheers

Chaals

-- 
Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org

Received on Friday, 1 April 2005 07:08:30 UTC