W3C home > Mailing lists > Public > public-tt@w3.org > October 2008

RE: Agenda for 10th Oct

From: De Jong, Frans <dejong@ebu.ch>
Date: Fri, 10 Oct 2008 14:43:20 +0200
Message-ID: <9BB211A65FCBFD43B95F67BA2485759D0FF05BEC@gnvasmail1a.gva.ebu.ch>
To: "Glenn A. Adams" <glenn@xfsi.com>, "Sean Hayes" <Sean.Hayes@microsoft.com>, "Public TTWG List" <public-tt@w3.org>
Cc: "Andrew Kirkpatrick" <akirkpat@adobe.com>, "Matt Morgan-May" <mattmay@adobe.com>

I am unfortunately unable to join today.

Frans de Jong
Senior Engineer EBU TECHNICAL

EBU TECHNICAL - your reference in media technology and innovation
European Broadcasting Union, http://tech.ebu.ch

L'Ancienne Route 17A, CH-1218 Grand Saconnex, Geneva, Switzerland 

Tel:          +41 22 717 2722
e-mail:     dejong@ebu.ch

-----Original Message-----
From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf
Of Glenn A. Adams
Sent: vendredi, 10. octobre 2008 14:37
To: Sean Hayes; Public TTWG List
Cc: Andrew Kirkpatrick; Matt Morgan-May
Subject: Re: Agenda for 10th Oct

Some input, prior to teleconf:

On 10/10/08 6:19 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> 8. Discussion items and errata
>     a) metadata.
>         Why do we need to allow more than 1?

The tt:metadata element was designed first as a location context sensitive
container for non-TT related metadata vocabulary, i.e., vocabulary defined
in some non TT namespace, and second, as a similar grouping element (of
convenience) for TTM vocabulary. You will notice that, when expressed in
content elements, the semantics of any metadata information contained in the
Metadata.class elements are said to apply to the element in which it appears
as a child, as well as that element's descendants. As such, the metadata
information is semantically tied to its location of specification in the
element tree. In the case of tt:head, any Metadata.class element is said to
apply to the document as a whole. If you recall, one of the purposes of the
metadata element was to serve as a container for Dublin Core metadata, and,
in that regard, it is consistent to permit its specification in multiple

>         Should ttm:* elements be children of metadata, or can we get rid
> metadata?

As the DFXP schema is currently specified, it is the option of the author to
place ttm:* elements in a containing tt:metadata element. This is more a
matter of convenience and grouping that the author can exploit as they wish.
I think this is a useful convenience that should not be jettisoned. Nor
should tt:metadata be removed for the reasons outlined above.

>           Should desc be description?

As is described by Annex I, tt:desc is modeled on svg:desc, which uses the
abbreviated name 'desc'. Note that tt:metadata and ttm:title were also based
on similar SVG vocabulary, svg:metadata and svg:title.

>         b) timing.
>                 i) spec issue. default values for many parameters not
> specified by : xxx
>                in particular default timing semantics for region, p and
> are not defined.

Actually, I believe that 10.4 Time Intervals addresses this issue fully.

>              ii) spec issue. reference to SMIL should be S 10.4.1 not


>              iii) duration has error in spec (<digit>+)
> duration>


>   : <digit> ( "." <digit>+ )? metric
> metric
>   : "s"                 // seconds
>   | "ms"                // milliseconds
>   | "f"                 // frames
>   | "t"                 // ticks

This email and any files transmitted with it 
are confidential and intended solely for the 
use of the individual or entity to whom they
are addressed. 
If you have received this email in error, 
please notify the system manager.
This footnote also confirms that this email 
message has been swept by the mailgateway
Received on Friday, 10 October 2008 12:44:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:03 UTC