RE: Coments - last call draft

Hi Charles,

Thanks much for your comments. Following are some personal
replies/comments. The TT WG will follow up with a consensus response.

G.

> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@sidar.org]
> Sent: Wednesday, March 30, 2005 8:46 PM
> To: public-tt@w3.org
> Subject: Coments - last call draft
> 
 
> 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.

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.
 
> 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.
 
> 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.

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.

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)?
 
> 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).

> 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.

Agreed. This is on my action item list.
 
> 6. Compulsory xml:lang attribute
> 
> Cool idea.

A legacy of my days working on I18N.
 
> 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.)
 
> 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.

> 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.

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.

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

Good idea.

Received on Thursday, 31 March 2005 14:54:44 UTC