RE: DIWG Response to the Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements

Glenn, 

On behalf of the DIWG, can I thank you and the TTWG for your careful consideration of our comments. You have covered all of the points we made with appropriate actions. We hope you found the exercise useful.

Very best wishes

Rhys

-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 08 January 2004 18:06
To: W3C DIWG (E-mail); Rhys Lewis
Cc: public-tt@w3.org
Subject: RE: DIWG Response to the Timed Text (TT) Authoring Format 1.0
Use Cases and Requirements



Dear DIWG,

The TTWG has reviewed your comments on [1] and provides the
following responses (inserted inline below).

[1] http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915/

We greatly appreciate your efforts to review and comment, and
understand that this requires valuable resources to accomplish.

Regards,
Glenn Adams, Chair, for TTWG

> From: Rhys Lewis <rhys.lewis@volantis.com> 
> Date: Thu, 20 Nov 2003 15:14:05 -0000
> To: <public-tt@w3.org> 
> Cc: "W3C DIWG (E-mail)" <w3c-di-wg@w3.org> 

> 1) Section 1.2
> 
> In section 1.2 System Model, the term Transcoding is used to
> represent the tranformation between the timed text authoring fomat
> and the distribution format. Transcoding is one particular
> implementation that may be used during adaptation (definition at
> http://www.w3.org/TR/di-gloss/#def-adaptation). Others include
> selection among alternative representations. Indeed, selection within
> the authoring format is considered explicitly in Requirement R207.
> This is an important distinction. Transcoding essentially transforms
> between different representations of the same information. This is
> not always sufficient when dealing with devices with very different
> capabilities. Issues for authors associated with supporting a wide
> variety of devices are discussed in Authoring Challenges for Device
> Independence (see http://www.w3.org/TR/acdi/).
> 
> As the document under review is a set of use cases and requirements,
> DIWG feels it would be appropriate to acknowledge that transcoding is
> not the only transformation that might be applied to timed text. We
> suggest that section 1.2 and Figure 1 be updated to include
> alternative transformations as well as transcoding. It would probably
> be sufficient to lablel one of the boxes in the figure as
> Transformation rather than Transcoding. This would have the benefit
> of making explicit in the figure the statement about use of the
> proposed new format as a distribution format.

We agree that the term "transcoding" is not sufficiently general, and
will change to "transformation" and "transformed" as appopriate. Thank
you for pointing out your glossary of terms.

> 2) Requirement R109 Transformability
> 
> Requirement R109, the list of legacy formats covers transformation to
> legacy formats. DIWG feels that it might be useful to mention
> adaptation in the context of this requirement. In addition, the list
> of legacy formats to be supported appears to be informative but might
> be read as normative. A normative list might be more appropriate for
> a requirements document.

As indicated by the Note under R109, the list is explicitly
informative.  However, since we are not mandating that any of these
formats be normative targets of transformation, and to make it more
logically consistent, we will change "shall be capable of being
transformed into..." to "should be capable of being transformed
into...".

> 3) Use of XSL-FO
> 
> The document makes heavy use of terminology from XSL and in
> particular XSL-FO. It would be useful to add a statement about
> whether the use of XSL-FO for styling has actually been assumed. If
> there are no such assumptions, it would be useful to add some
> reassurance that styling will be possible using other mechanisms,
> particularly CSS. This is potentially important to manufacturers of
> mobile devices, interactive television systems and other devices with
> limited resources. The 'footprint' of software that such
> manufacturers need to provide to support W3C recommendations is a
> constant challenge given the restricted resources available to them.

As is clear from the title and introduction of this document, the
intended use of this work is as an authoring format, and not a
distribution format. Although we do not exclude its use as a possible
distribution format, we have not made any special provisions for this
use. As a consequence, your comment about use with limited resource
devices is not expected to be relevant, since a transformation from
the TT Authoring Format to a distribution format suitable for the
target user agents is implied.

Regarding use of XSL FO vocabulary, we have adopted this vocabulary
in certain cases for the purpose of describing authorial intention
and presentation semantics. This usage does not imply that the same
vocabulary must be used in a distribution format or will be visible
to user agents for some distribution format.  We believe that the
XSL FO vocabulary we have adopted can be readily transformed into
XHTML + CSS or SVG in most cases, although some loss of generality
is to be expected to occur in such a transformation.

Notwithstanding the above, if the DIWG is aware of any authorial
related usage of the indicated subset of XSL FO vocabulary that would
make transformation into a distribution format impossible or difficult,
then we would be interested to learn more details.

> 4) Normative or Informative Lists
> 
> Finally, DIWG also felt that would be helpful if appropriate
> statements could be added defining whether or not the various sets of
> enumerated values, for items such as styles, is intended to be
> normative or informative. DIWG assumes that these are intended to be
> normative.

As is the policy in other W3C standards documents, unless it is
explicitly marked as informative, or appears in a note or an example,
then it is normative. However, to make this clear, we will add
a sentence in the introduction indicating this to be the case.

**********************************************************************

Received on Wednesday, 14 January 2004 03:16:06 UTC