Re: Issue-382 review

Thanks, looks good to me.

Nigel

On 04/05/2015 20:42, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

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



-----------------------------
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 Tuesday, 5 May 2015 15:34:52 UTC