- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Mon, 4 May 2015 12:42:01 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: TTWG <public-tt@w3.org>
Hi all, I have implemented these changes in https://dvcs.w3.org/hg/ttml/rev/14e47051b5af Best, -- Pierre On Fri, May 1, 2015 at 7:57 AM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > Hi Nigel, > >> 1 and 2 and 4 > > Looks like improvements to me, which I plan to implement unless I hear > otherwise. > >> 2 > > Looks good to me. > >> 3 [...] so if different clock-time expression formats >> are mixed is that in the spirit of the >> recommendation or not? > > It is in the spirit (and to the letter) of the recommendation, so no > change needed in my opinion. > > Best, > > -- Pierre > > > > On Fri, May 1, 2015 at 7:42 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: >> I've reviewed Pierre's change set for resolving Issue-382 and have added >> the following comment, repeated below for ease of access: >> >> [[ >> Review notes: >> >> 1. The changeset has highlighted some wording that I didn't previously >> notice: >> >> "ttp:tickRate shall be present on the tt element if the >> #time-offset-with-ticks feature is used in the document." >> >> This is problematic because it isn't clear if it means that the document >> expresses a profile requirement for the #time-offset-with-ticks feature or >> if it means that the document includes any time expressions that require >> the processor to have the feature. I suggest changing it to: >> >> "ttp:tickRate shall be present on the tt element if the document contains >> any time expression that uses the t metric." >> >> 2. Looking at the wording for #frames: >> >> "If the document includes any time expression that uses the frames term, >> the ttp:frameRate attribute shall be present on the tt element." >> >> It doesn't say if the feature may be used or not, and omits the >> possibility of offset times with f metric. It may better be written as: >> >> "MAY be used, with the following additional constraints: If the document >> includes any clock time expression that uses the frames term or any offset >> time expression that uses the f metric, the ttp:frameRate attribute SHALL >> be present on the tt element." >> >> >> The #timing feature has two SHOULD constraints, but neither of them is >> totally clear. >> >> 3. The first is that the same time expression should be used throughout, >> and then it says 'either clock-time or offset-time' - but there are syntax >> choices within either clock-time or offset-time; so if different >> clock-time expression formats are mixed is that in the spirit of the >> recommendation or not? e.g. would <p begin="00:10:00.375" >> end="00:10:02:15"> be okay? >> >> 4. The second is that the new constraint doesn't take into account the >> hierarchy. I'd suggest amended wording such as: "begin and end attributes >> SHOULD be specified on at least one ancestor of every content element that >> contains br elements or text nodes, i.e. a span, a p, a div or a body." >> >> ]] >> >> Some of those comments are beyond the scope of the original issue but were >> highlighted because Pierre tidied the formatting - sorry for catching them >> so late! >> >> >> Kind regards, >> >> Nigel >> >> >> >> >> ----------------------------- >> http://www.bbc.co.uk >> This e-mail (and any attachments) is confidential and >> may contain personal views which are not the views of the BBC unless specifically stated. >> If you have received it in >> error, please delete it from your system. >> Do not use, copy or disclose the >> information in any way nor act in reliance on it and notify the sender >> immediately. >> Please note that the BBC monitors e-mails >> sent or received. >> Further communication will signify your consent to >> this. >> -----------------------------
Received on Monday, 4 May 2015 19:42:50 UTC