Timed Text Working Group Teleconference

28 Jan 2016

See also: IRC log


nigel, andreas, pierre, shinjan, glenn, tmichel, dae


<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


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


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


nigel: Okay I guess we'll close this one.

close action-454

<trackbot> Closed action-454.


<trackbot> action-455 -- Glenn Adams to Update ttml2 spec/readme to include config for keyword replacement. -- due 2016-01-28 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/455


<trackbot> action-445 -- Andreas Tai to Propose to mdolan this addition to the profile registry document. -- due 2015-11-06 -- OPEN

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


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


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 https://github.com/w3c/imsc/issues/125 Unable to normatively determine non-conformance when testing content constraints.

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 scribe.perl version 1.144 (CVS log)
$Date: 2016/01/28 16:33:11 $