W3C home > Mailing lists > Public > public-tt@w3.org > October 2014

Re: IMSC1 WD wide review and CR draft.

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Wed, 15 Oct 2014 09:49:26 +0000
To: Thierry MICHEL <tmichel@w3.org>, Pierre-Anthony Lemieux <pal@sandflow.com>
CC: W3C Public TTWG <public-tt@w3.org>, Philippe Le Hegaret <plh@w3.org>
Message-ID: <D0640016.145B3%nigel.megitt@bbc.co.uk>
On 14/10/2014 17:16, "Thierry MICHEL" <tmichel@w3.org> wrote:

>[adding PlH]
>
>On 14/10/2014 17:50, Nigel Megitt wrote:
>> Thierry,
>>
>> thanks for preparing this. For folk having trouble accessing the CR
>>draft
>> the correct link is:
>>
>> [1] http://www.w3.org/2014/09/WD-ttml-imsc1-20141014/Overview.html

>>
>>
>> Exit Criteria
>>
>> The exit criteria stated here include a requirement for two independent
>> interoperable implementations of each feature. Many times I've been told
>> that there is no W3C process requirement for this criterion. So that we
>> can make the best decision when choosing the appropriate exit criteria
>> from this CR, please could you outline the options that we have here?
>
>The "two independent interoperable implementations of each feature", is
>the regular exit criteria, that most Draft go throught (at least with
>the former 2005 Process). Note that each implementation does not
>necessary covers all features.
>
>If you want some different exit criteria, you will make your case to the
>Director when requesting transition to CR.
>
>This is what will be asked for transition to CR (new 2014 Process) about
>Implementation:
>
>- The group must document how adequate implementation experience will be
>demonstrated. Are there tests or test suites available that will allow
>the WG to demonstrate/evaluate that features have been implemented
>(e.g., a matrix showing how different pieces or classes of software
>implement different features)? Is the expectation to show two complete
>implementations (e.g., there are two software instances, each of which
>conforms) or to show that each feature is implemented twice in some
>piece of software?
>- What are the Group's plans for showing implementation of optional
>features? In general, the Director expects mandatory features and
>optional features that affect interoperability to be handled similarly.
>Optional features that are truly optional (i.e., that do not affect
>interoperability) may require less implementability testing.
>- Does the WG have additional implementation experience that will help
>demonstrate interoperability (e.g., has there been an interoperability
>day or workshop? Is one planned?)?

Is this your summary or does it come from a document, and if a document,
can you send a link? The 2014 process [1] says:

"7.2.4 Implementation Experience

Implementation experience is required to show that a specification is
sufficiently clear, complete, and relevant to market needs, to ensure that
independent interoperable implementations of each feature of the
specification will be realized. While no exhaustive list of requirements
is provided here, when assessing that there is adequate implementation
experience the Director will consider (though not be limited to):

* is each feature of the current specification implemented, and how is
this demonstrated?
* are there independent interoperable implementations of the current
specification?
* are there implementations created by people other than the authors of
the specification?
* are implementations publicly deployed?
* is there implementation experience at all levels of the specification's
ecosystem (authoring, consuming, publishing…)?
* are there reports of difficulties or problems with implementation?

Planning and accomplishing a demonstration of (interoperable)
implementations can be very time consuming. Groups are often able to work
more effectively if they plan how they will demonstrate interoperable
implementations early in the development process; for example, they may
wish to develop tests in concert with implementation efforts."

I presume the answer to all the questions is supposed to be 'yes', but
that's not clear. 



[1] http://www.w3.org/2014/Process-20140801/#implementation-experience


>
>
>
>>
>>
>> Review end date
>>
>> I'm unsure right now when we will /enter/ CR, but specifying an end date
>> no sooner than 31 December may appear provocative to some, depending on
>> how long the minimum review period ends up being, because it is during a
>> time when many folk take holidays. It may be more appropriate to set the
>> end date a little later (or even earlier), noting that we may hit a
>>heavy
>> period of comment reviews when we think about TTML2 as well - our
>> timetable has the TTML2 pre-CR WD review period ending mid-January right
>> now.
>
>Remember that this is a minimum review date.
>Per W3C process  it must be at least four weeks after publication.
>
>http://www.w3.org/2014/Process-20140801/#candidate-rec

>
>So depending on the CR publication, we will setup that date. It is a no
>brainer.
>
>>
>> Kind regards,
>>
>> Nigel
>>
>>
>>
>> On 03/10/2014 15:32, "Thierry MICHEL" <tmichel@w3.org> wrote:
>>
>>> Pierre, Nigel, TTWG,
>>>
>>> Now that we have published the IMSC1 WD for wide review, we should be
>>> tracking incoming comments on public-tt@w3.org.
>>>
>>> If there are comments coming in, we should discuss those, by email or
>>> during calls, or at F2F and come to a WG resolution. Then the WD should
>>> respond to each commenter to collect his approval.
>>> (We don't necessary have to accept the proposal from the commenter, but
>>> if we don't, we should explain  why it is only partially
>>> adopted/postponed or rejected/, etc.
>>> Finally, if the commenter does not agree to our resolution, we will
>>>make
>>> our case to the Director.
>>>
>>> In parallel we should start working on the CR draft.
>>>
>>> Therefore I have drafted the SOTD section [1]  for this CR, that Pierre
>>> may incorporate in his document.
>>>
>>> Please look at the exit criteria and the end date of CR (set for 31 dec
>>> 2014), and let's discuss those.
>>>
>>> Thierry.
>>>
>>>
>>> [1] https://www.w3.org/2014/09/WD-ttml-imsc1-20141014/

>>>
>>>
>>

Received on Wednesday, 15 October 2014 09:49:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:18 UTC