- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 28 Jan 2016 16:34:32 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D2CFF35D.335BD%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2016/01/28-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
28 Jan 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/01/28-tt-irc
Attendees
Present
nigel, andreas, pierre, shinjan, glenn, tmichel, dae
Regrets
frans
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]Action Items
3. [6]IMSC issues
4. [7]Commit policy on github
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<tmichel> I will be a few minutres late ...
<scribe> scribe: nigel
This Meeting
nigel: [Goes through likely topics for meeting]: Actions, IMSC
1 issues, TTML2, possibly profiles
... Any specific topics to cover, or AOB?
pal: IMSC 1 issues please
nigel: Yes
glenn: I'd like to discuss commit policy on github
nigel: Okay
Action Items
action-453?
<trackbot> action-453 -- Thierry Michel to Schedule between
tmichel and philippe the transition to cr3 with any director
call as needed. -- due 2016-01-21 -- PENDINGREVIEW
<trackbot>
[10]http://www.w3.org/AudioVideo/TT/tracker/actions/453
[10] http://www.w3.org/AudioVideo/TT/tracker/actions/453
tmichel: IMSC 1 CR3 is published and has been announced to AC
and Chairs, and triggered a 2 month patent exclusion
close action-453
<trackbot> Closed action-453.
tmichel: I had to extend the CR exit point to Feb 28 because we
moved the publication back by 2 days.
nigel: Thanks
pal: I'll modify that on github too - Feb 28?
tmichel: Feb 28 yes
nigel: Thanks everyone whose helped with publication of that
CR.
action-454?
<trackbot> action-454 -- Philippe Le Hégaret to Create stub
files to redirect from hg to github for ttml1 and ttml2 -- due
2016-01-28 -- PENDINGREVIEW
<trackbot>
[11]http://www.w3.org/AudioVideo/TT/tracker/actions/454
[11] http://www.w3.org/AudioVideo/TT/tracker/actions/454
glenn: I noticed on the CR3 that a message was issued, a call
for exclusions message. Is a call for exclusions a
... multiple event or a single event? Normally in the past
process a call for exclusions only occurred on the first CR
... but not subsequent CRs. Has that changed?
tmichel: It's actually the com team who does that. I don't
remember - I need to check if we sent an exclusion for the
... 2nd CR and will look into it and let you know. My
interpretation is every CR publication triggers an exclusion
... period of 2 months, but I will investigate.
... It makes sense because if you add functionality into the CR
version then it may result in a patent exclusion.
glenn: I agree.
action-454?
nigel: Okay I guess we'll close this one.
close action-454
<trackbot> Closed action-454.
action-455?
<trackbot> action-455 -- Glenn Adams to Update ttml2
spec/readme to include config for keyword replacement. -- due
2016-01-28 -- OPEN
<trackbot>
[12]http://www.w3.org/AudioVideo/TT/tracker/actions/455
[12] http://www.w3.org/AudioVideo/TT/tracker/actions/455
action-445?
<trackbot> action-445 -- Andreas Tai to Propose to mdolan this
addition to the profile registry document. -- due 2015-11-06 --
OPEN
<trackbot>
[13]http://www.w3.org/AudioVideo/TT/tracker/actions/445
[13] http://www.w3.org/AudioVideo/TT/tracker/actions/445
atai: I checked with Mike and will make a proposal for a new
column for the profile registry table that shows where
... the profile information can be found inside the TTML
document instance for the corresponding TTML profile
specification.
... Some are for ttp:profile attribute, or element, or
ebuttm:documentConformsToStandard element.
mike: Andreas and I exchanged a couple of emails and it makes
sense to me.
... I'm hopelessly behind on the profile document!
nigel: What can I do to help?
mike: The wiki is what I think we want to produce, in the text.
It's more about putting it into a document template
... and using the tools to publish it in W3C.
nigel: Thierry, would you be able to assist?
tmichel: Yes, I'd be happy to help turn the wiki text into a
first version on github
action-429?
<trackbot> action-429 -- Mike Dolan to Draft a wg note for the
profile short name registry and ttml media type registration --
due 2015-10-08 -- OPEN
<trackbot>
[14]http://www.w3.org/AudioVideo/TT/tracker/actions/429
[14] http://www.w3.org/AudioVideo/TT/tracker/actions/429
action-429: [TTWG meeting 2016-01-28] tmichel to help this
along with a first draft on github
<trackbot> Notes added to action-429 Draft a wg note for the
profile short name registry and ttml media type registration.
close action-445
<trackbot> Closed action-445.
IMSC issues
pal: I'd like to start with issue #127
[15]https://github.com/w3c/imsc/issues/127
[15] https://github.com/w3c/imsc/issues/127
nigel: Extensibility goals not documented
pal: The discussion is whether or how IMSC 1 can have an
opinion on IMSC 2 and how an IMSC 1 document will be
... processed by an IMSC 2 processor and vice versa. Before we
have started on IMSC 2 it is very difficult to have a
... good opinion. I think we should have that discussion when
we start on IMSC 2.
glenn: The issue here is whether we address this in IMSC 1 or
wait. I'm insisting on addressing it in IMSC 1 and not
... waiting. I agree that it needs a bit of thinking. We don't
have to refer to IMSC 2, we can simply refer to future
... versions. At least TTML2 talks about future and past
versions.
... In retrospect we should have given more thought to
extensibility and at least documented our goals. I'm asking
... for informative material that describes our goals. It would
be a sad state of affairs if we cannot document our goals now.
pal: I don't think this is as dire as you just painted it. IMSC
1 already allows foreign vocabulary, which allows for
... straightforward extensibility.
glenn: It may be sufficient to describe those goals, for
example the goal of supporting vocabulary not in IMSC 1.
pal: That's §6.2
glenn: I'm asking for a specifically labelled section on goals,
in an annex, the introduction or somewhere else.
pal: Okay. I don't really know how to write that section. I'd
like to consider a concrete proposal.
glenn: I hope people already have goals in mind and could
articulate them.
... Foreign vocabulary is one goal. The same comments are going
to apply with #126 on interoperability.
nigel: [opens up to group to offer options for extensibility]
glenn: Both forward and backward compatibility come into this
category. I would hope that a goal is to be as
... forward and backward compatible as possible, as a generic
goal that applies to most of W3C development.
... That doesn't mean it's not possible to create a breaking
change in the future. If we think that such a breaking change
... could occur then we could document it as a discussion
point.
nigel: One of the points I think is probably implied is that
the purpose of the profile exercise is that extensions from
within TTML are excluded unless listed.
glenn: Since we don't list all the features there's an
implication that unlisted features from TTML 1 are permissible
in IMSC 1, yes?
pal: We put a significant effort in to list all TTML 1 profile
features.
glenn: Okay, so all features from TTML Annex D are listed as
prohibited or permitted, yes?
pal: Yes, that was the goal, and I think we achieved it.
glenn: We could argue about if that's extensibility or
interoperability, but it is possibly both, so we could discuss
that under extensibility goals.
... I suggest we open this up for comments over the next couple
of weeks and that I will draft a proposal based on that.
nigel: Those comments should be on the github issue
pal: What are we asking people to do?
glenn: Give us opinions on what are and are not extensibility
goals.
... I haven't written down my own thoughts on this yet. I'm
more struck by the absence of this topic than anything else.
That was my point in filing the issue.
... I'm prepared to draft something but can't articulate my own
thinking on this right now.
nigel: I think we should be careful to understand if we need
this or if we can build on something already in TTML1
... by inheritance?
glenn: I don't think we have extensibility goals described in
TTML1
... which in retrospect we should have put in.
... In TTML1 we used a QA guideline checklist. One of the
points there was a set of good practices. Number 18
... states that if extensibility is allowed define an extension
mechanism.
... I suggest we review what's in IMSC 1 and TTML 1 and go from
there.
nigel: Okay so action on everyone to complete this research and
record their goals in the issue.
glenn: Very much the same comments apply to the
interoperability issue.
pal: What's the time box that we have on this?
glenn: I can respond by mid-Feb with some material.
nigel: Okay, that sounds like 2 weeks to note extensibility and
interoperability goals in the github issues.
pal: How are we doing on #111 and #114?
glenn: I've got to draft some material based on a conversation
I had with Nigel, where we think we may be able to resolve both
of those.
... Mid-Feb is reasonable for those too.
pal: #125 [16]https://github.com/w3c/imsc/issues/125 Unable to
normatively determine non-conformance when testing content
constraints.
[16] https://github.com/w3c/imsc/issues/125
glenn: At present IMSC 1 specifies that if a document is not
conformant then behaviour is undefined. Correct?
pal: Correct. The document does not specify a normative
behaviour in the presence of a non-conformant document.
glenn: A couple of points: 1. Since all behaviour re
non-conformance is unspecified then it is impossible to
normatively
... test non-conformance because any outcome is possible, from
aborting to ignoring and anything in between.
... I'm not happy with that state of affairs. Part 2, which I
did make a proposal for, is to introduce the concept of a
... validating processor and to allow for some normative
behaviour in the face of non-conformance if and when the
... IMSC processor is also a validating processor. So an IMSC
transformation or validation processor that also supports
... validation and it is enabled then it is possible to define
some constraints on non-conformance.
atai: I thought the conclusion here from previous meetings when
we discussed this is that handling of non-conformant
... files is out of spec and I agree with that. What Glenn
wants to define is behaviour on encountering non-conformant
documents.
... I think that's out of scope of the spec. The topic came up
before and from what I read of the minutes the conclusion
... was out of scope.
pal: That's my recollection, but it sounds like Glenn is
proposing something a little narrower, only for validating
processors.
... So for those who choose to describe processors as
validating then this is the behaviour.
glenn: That's right. I don't disagree with Andreas but I think
we can do better than that at little or no cost to the
specification.
... For example the TTT toolset has a presentation engine in
it. It performs validation processing as a precursor to
... presentation. It's an existing implementation (also of a
transformation processor) that does implement the optional
... features of validation. So we can go further than saying
it's completely out of scope and having normative
... language that allows us to introduce defined behaviour.
pal: The particular thing here is that it's a class of
processors described as validating processors.
glenn: Yes, TTML2 introduces these all formally along with some
specific vocabulary for controlling it. I didn't want
... to inject that into this proposal because that would be
going too far, but I took the semantics of what we're
... proposing and put them into a form that we could adopt in
IMSC 1.
atai: Thank you for the clarification. It is of course a
different use case. I would like to see the concrete proposal.
... There are of course existing possibilities to check
conformance, for example using an XML schema. This already
... has a defined behaviour for how to identify
non-conformance. I'm not sure if we should also define
behaviour for
... QC processes of TTML.
glenn: Take a look at #125 because there is a proposed set of
language there.
Commit policy on github
glenn: There are two kinds of policies that are commonly used
in development - Review Then Commit, when a
... consensus approval is obtained prior to a commit. Then
there's Commit Then Review, which allows a
... retroactive veto. In the history of this group all of the
work on TTML1 and TTML2 in Mercurial and CVS was done
... on a Commit Then Review (CTR) lazy consensus process. It
was based on the editor to decide when to commit
... and then notify the group and make sure that they had log
info to give them a chance to review post facto and
... object if necessary. Most teams follow a CTR process
because it provides the least barriers to making changes.
... It can result in more bugs potentially. My experience is
I've worked with both kinds of processes. With github
... which has a Pull Request mechanism it is possible to
snapshot the changes and call them out for review. We
... discussed and agreed the move to github in Sapporo and
talked about the review process but I don't recall doing
... so in depth. At the time I remember thinking it should be
up to the Editor to decide how to use that facility. I never
... anticipated changing from CTR to RTC. Recently both Nigel
and Pierre have in the context of IMSC 1 been following
... a RTC process in their thinking. I would object to that for
TTML2. I might be willing to agree to it for other work.
... I find it a strong barrier to process. For example right
now I have 4 different issues that Pierre has delegated to me
... to create PRs. All of those fixes are going to change the
same lines of code.
pal: I think there's a misunderstanding - you can create a PR
that covers multiple issues, and we've done that in the
... past.
glenn: I agree that's possible.
nigel: github also provides a tool for merging work in other
branches to resolve the clashes.
glenn: I agree there are tools there but it's much more awkward
and difficult to do that. My basic point is that
... we don't have a firm consensus on CTR or RTC as a policy.
Secondly even if we are using RTC on e.g. IMSC 1 I don't
... think it should be a blanket policy but up to the Editor to
decide what policy to use. For trivial changes there's
... no reason to follow the more time consuming process.
atai: I think we should check again what we discussed at TPAC.
I think we explicitly had some discussion about the
... new policy with github and I thought we agreed but I'm not
sure.
nigel: We did discuss this in Sapporo and I'm pretty sure we
did agree that. For WDs we always followed a RTC process
... and said that to reduce the time between ED updates and WD
publications and to use the automated WD publication
... tool we would use PRs.
glenn: I do recall saying that I wouldn't be happy to adopt
this for TTML2.
nigel: I'm happy to review the notes on this and return to it
as a topic. In the meantime I would also like plh's views
... and I would myself strongly recommend that we use pull
requests for everything including TTML2.
glenn: I don't mind using pull requests but I object to a 2
week period before a merge is permitted.
... I think it should be up to the Editor or possibly the Chair
to decide to merge if a change is non controversial and
... not to impose a 2 week delay on all PRs.
nigel: That's coincident with what we said in Sapporo. There
may be a middle ground there that is actually acceptable.
glenn and pal: [discussion without conclusion on who should be
allowed to merge pull requests]
nigel: We're out of time now so I'll adjourn. An hour again,
same time next week. Thanks everyone [adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [17]scribe.perl version
1.144 ([18]CVS log)
$Date: 2016/01/28 16:33:11 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
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 Thursday, 28 January 2016 16:35:19 UTC