Re: Issue-382 review

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