W3C home > Mailing lists > Public > public-tt@w3.org > January 2004

RE: Comments on Working Draft "Timed Text (TT) Authoring Format 1.0 Use Cases and Requirements"

From: <guido.grassel@nokia.com>
Date: Fri, 9 Jan 2004 11:24:06 +0200
Message-ID: <1608B4661DA6D84C9503F2DF97184CDA02097CBD@esebe006.ntc.nokia.com>
To: <gadams@xfsi.com>, <public-tt@w3.org>
Cc: <Art.Barstow@nokia.com>


Dear Glenn, dear TTWG members,

Thank you for considering our comments and sending a detailed response.

GG 09-01: While reviewing your response I noticed that a reference to the TTWG charter is missing. In fact, I can not find it from the TTWG public Web pages either. Reference to the charter is important because requirements need to reflect what the TTWG has been chartered to produce. Searching the W3C site I found a document at http://www.w3.org/AudioVideo/TT/ttcharter20020901.html In the following, I assume this doc is the charter of the TTWG. I will refer to it as "the charter".

Feedback to your disposition of comments below, marked as "GG 09-01:".

BR
- Guido
-----Original Message-----
From: ext Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: Thursday, January 08, 2004 8:10 PM
To: Grassel Guido (Nokia-NRC/Helsinki); Barstow Art (Nokia-TP/Boston)
Cc: public-tt@w3.org
Subject: RE: Comments on Working Draft "Timed Text (TT) Authoring Format
1.0 Use Cases and Requirements"



Dear Guido,

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 Nokia's efforts to review and comment, and
understand that this requires valuable resources to accomplish.

Regards,
Glenn Adams, Chair, for TTWG

> From: <guido.grassel@nokia.com> 
> Date: Mon, 8 Dec 2003 14:41:28 +0200
> To: <public-tt@w3.org> 
> Cc: <guido.grassel@nokia.com>, <Art.Barstow@nokia.com> 

> NOK-1: The TT AF should not duplicate functionality that can already
> be found from existing or upcoming W3C Recommendations. Instead it
> should adopt useful functionality from W3C languages such as SMIL,
> XHTML, SVG or CSS. We request adding such a requirement to section
> 4.1. 

We interpret this requirement as stating essentially the following:
"don't invent something new [unless you have a good reason to do so],
and in case you don't invent, then adopt an existing W3C technology".

Although we view this as a very basic requirement under which we have
been operating, we have no objection to documenting it as such;
therfore, we will add a new general requirement to this effect.

GG 09-01: OK

> NOK-2: Use of the TT AF in combination with SVG and SMIL are very
> important and should be mentioned as a requirement. For instance, it
> should be possible to use the TT AF as a 'textstream' media object in
> a SMIL presentation.

The current work (and requirements) document focuses solely on the
specification and use of an authoring content format, and not a
distribution format. 

Since SMIL is effectively designed to work with distribution formats
for use by its media objects, we believe it is best to not explicitly
define such usage in the TT Authoring Format Requirements.
Nevertheless, we recognize the need for such a usage, and intend to
address that as possible future work of the TTWG. In this regard, we
would solicit Nokia's participation in helping define such a
distribution format.

Note that the current requirements document does not exclude the
use of the authoring format as a distribution format; so, it would be
possible, though perhaps not desirable, to use the authoring format
directly as content referenced by a text media object in SMIL. Keep
in mind, however, that it is unlikely that the current authoring
format will be expressed in a format that is suitable for streaming,
particularly not suited for arbitrary stream entry points.


GG 09-01: The definition of the scope of the TTWG in the charter reads (1st bullet): "Develop a new Timed Text format that integrates well with other W3C technologies.". I think this is a clear requirement to the TTAF. See also comments on NOK-3.



> NOK-3: Use of the TT AF as a distribution format is insufficiently
> represented in use cases and in requirements. It appears that the TT
> AF is primarily intended as an authoring format that serves as input
> to a transcding process into a proprietary distribution format. Use
> of the TT AF as distribution format should be at least equally
> important as serving as an authoring format.

Your observation is correct. And we do view a distribution format as
important as an authoring format. However, we do not agree that use of
the authoring format directly as a distribution format is desirable.
Further, we have determined that the group should take up the formal
definition of a distribution format only after we have completed an
authoring format.

One of the primary requirements driving an authoring format is the
existence of many distribution formats, with none of these being
sufficient as an authoring format interchange standard. As a
consequence, our current focus is on satisfying this need rather than
adding one more item to the already large set of distribution formats.

As a side-bar, we have already noted that SVG would be a reasonable
distribution format.

GG 09-01: This plan to make two specifications does not become clear to the reader of the reviewed requirements document. Furthermore, the charter talks about specifying one format not two.

It is not clear to me why a TT format can not serve both authoring and distribution formats. Why is TT different from other Web technologies? The TT group should provide clear evidence that specification of two formats has advantages over the specification of one format. 

There are use cases where a person wants to first read a TT document and modify (re-use) this content afterwards. This use case can likely not be supported with separate authoring and distribution formats. Person-to-person messaging in the mobile domain, e.g. Multimedia Messaging (MMS) is one example for this use case. As of today, the highest use of synchronized multimedia and SMIL is in MMS.

In summary, we disagree with the specification of two separate formats, one for authoring and another one for distribution, instead of one format that can serve both purposes.

> NOK-4: A "Basic" language profile of the TT AF should also be defined
> that is suitable for distribution to constraint embedded devices such
> as mobile terminals. We request adding such a requirement to section
> 4.1. 

We have discussed the issue of defining profiles for the authoring
format and have determined that the axis for determination should be
around authorial usage scenarios, e.g., subtitling versus captioning,
visual presentation versus aural presentation (via text to speech),
and so on.

When the TTWG does take up the definition of a distribution format,
then it is expected that device capabilities will be a determiner in
profiling the distribution format.


GG 09-01: A "Basic" profile is needed for a distribution format only.


> NOK-5 It must be possible to author TT documents in a device
> independent way. We request adding such a requirement to section 4.1. 

Because we have focused on an authoring format rather than a
distribution format, the current approach is effectively device
independent, since we are expressing authorial intention and not
expressing device behavior. However, if you should have specific
ideas about some features being device dependent, then please
let us know.


GG 09-01: Disagree. A format expressing author intention is not necessarily device independent. Author intentions are in many cases highly device specific. Some authors only have one specific (set of similar) devices) in mind when creating their content. This is a situation the Web needs to get away from.

Therefore, I encourage the TTWG to include this quite mild requirement. A more stringent requirement on DI would be the following: "The format should only allow to author TT documents that are device independent. The format should prevent that authors from creating documents that dependent on specific device properties."
Received on Friday, 9 January 2004 04:24:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:16:41 UTC