- From: Glenn A. Adams <glenn@xfsi.com>
- Date: Fri, 10 Oct 2008 20:36:37 +0800
- To: 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>
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
Received on Friday, 10 October 2008 12:37:21 UTC