RE: Agenda for 10th Oct

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

>         Should ttm:* elements be children of metadata, or can we get rid
of
> 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
span
> 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
10.3.1

agreed

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

Agreed

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