See also: IRC log
<scribe> scribe: nigel
nigel: Goes through agenda. AOB?
plh: I have an Emmy update.
pal: One specific topic: roadmap to PR for IMSC 1. I'd like to take 15 minutes to create a roadmap.
plh: Also charter
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> http://www.w3.org/AudioVideo/TT/tracker/actions/429
action-429: [TTWG meeting 2016-02-04] First draft now on github; also Andreas added a further column on the wiki page that needs to be included in the draft, for how to find profile information.
<trackbot> Notes added to action-429 Draft a wg note for the profile short name registry and ttml media type registration.
action-447?
<trackbot> action-447 -- Glenn Adams to Send pierre the list of which scripts are simple and which are complex. -- due 2015-11-06 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/447
action-447: [Meeting 2016-02-04] This has been resolved in the text and no longer needs to be done.
<trackbot> Notes added to action-447 Send pierre the list of which scripts are simple and which are complex..
close action-447
<trackbot> Closed action-447.
action-455?
<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
action-455: [meeting 2016-02-04] Nigel made the change but discovered the ant commands don't behave as expected; Glenn observed the same thing.
<trackbot> Notes added to action-455 Update ttml2 spec/readme to include config for keyword replacement..
close action-455
<trackbot> Closed action-455.
plh: [off the record update]
plh: I should have mentioned this
a few weeks ago - we should have sent the charter for review by
the end of this week already.
... We are not giving away extensions anymore. The AB has made
this clear. The minimum I can do is take the
... current charter, send it to the AC for review. If you want
to make more changes I'd like to know what those are.
pal: Is it possible to post it, give folks a week to comment and then close this next week?
<plh> https://www.w3.org/2014/03/timed-text-charter.html
plh: Of course!
... I'll put this current charter into a github repo before the
end of this call and people should make PRs to it and
... comments and let me know what needs to be changed. I hope
that we can send it to W3M for approval in the next 2
weeks,
... and to AC for review before the end of the month.
nigel: Sounds good to me.
... Thanks for the kick Plh, it's been in the back of my mind
for a couple of months!
plh: I'll send a message to the list also because obviously others need to be aware of it.
nigel: Thanks, let's work on this on github and return to the conversation next week.
<inserted> plh: http://w3c.github.io/charter-drafts/timed-text-charter-2016.html
<plh> for the charter, see https://github.com/w3c/charter-drafts/
https://github.com/w3c/tt-profile-registry
mike: Andreas updated the wiki so
those edits should be moved over to github.
... Folks ought to take a look at it. It needs a bit more work
on the rules for adding and changing things.
... Other than that it looks okay to me.
atai: I'll transfer the information from the wiki to github as a first step.
mike: Thanks Thierry for setting up the HTML page on github
nigel: That's the first action on this then, and then the next action will be for everyone to review it.
pal: There are a number of
related PRs regarding the test suite. Unless someone has an
issue with them I would like
... to merge all of them following this call. A quick
overview:
... This is in response to bugs and enhancements suggested both
to the formal test suite and additional tests
... In particular I'd like to point to PR #145 https://github.com/w3c/imsc/pull/145
... And PR #149 https://github.com/w3c/imsc/pull/149
which addresses an issue from PR #140 https://github.com/w3c/imsc/pull/140
... which unfortunately broke compatibility with EBU-TT-D. PR
#149 intends to correct that. I've not heard significant
... concerns with these. Fixing the bugs that were introduced
is really important so I'd like to proceed following the
call.
<atai> +1
glenn: Yes from me.
nigel: Fine for me.
pal: Okay thank you so I will do that.
pal: We seem really close so can we try to do this in 10 minutes.
glenn: I thought so, but there were changes made that I'm not happy with.
https://github.com/w3c/imsc/issues/111
pal: I posted an updated proposal just before the call.
nigel: I'm concerned that the different proposals don't share a lot of words. As Editor, Pierre can you take us through?
glenn: I don't want to solve a
determination of what profile a document instance conforms
to.
... What I'm proposing is to determine a profile to be used in
processing a document. The document instance may
... not conform to that.
+1
<inserted> [above +1 was from nigel]
pal: Okay and that sounds fine with me.
glenn: Pierre and I had some
offline discussion and I thought we were extremely close to
some common language
... but the latest update seems to be radically different.
pal: Okay I apologise for that - I didn't wish to introduce radical differences.
glenn: I also want to point to the multiple resolved profiles issue - it needs to be singular.
pal: On the second one I want to
understand what happens if a document signals conformance to
more than one
... profile e.g. using documentConformsToStandard..
glenn: Yes, could be. The profile that the processor uses is always a single profile ultimately.
pal: Okay so going back to the
proposal from 11 hours ago the first paragraph permits the
processor to pick a
... single profile out of many. Is that correct?
glenn: No there could be more than one.
pal: But the resolved profile is just one.
glenn: The process ultimately
comes to a single resolved profile. The initial step can
generate a set of profiles.
... The first paragraph describes the goal via the input
information and the ultimate result, a single resolved
profile.
... The paragraphs that follow show how that is achieved.
nigel: The second paragraph doesn't allow for multiple profiles being signalled.
pal: That's my point.
glenn: So could you explain how they could be signalled?
pal: ebuttm:documentConformsToStandard can have multiple values.
nigel: Or there could be more than one ttp:profile elements with different use attributes.
glenn: Okay I didn't notice that.
atai: You're still talking about an IMSC processor, correct?
pal: Thanks for raising that. As I read that it's a processor that supports IMSC I and/or IMSC T and also possibly other profiles.
atai: I thought we were just looking for IMSC I or IMSC T.
pal: I think Glenn's proposal covers profiles outside IMSC. I think that text would be best in the core TTML document by the way.
glenn: The intent of that text is
to be neutral on the subject of processors that support
multiple profiles.
... The answer could be IMSC-T, IMSC-I or undefined, from my
text. It's not intended to handle a 4th answer that may be some
other profile.
pal: Looking at the last comment on the thread...
https://github.com/w3c/imsc/issues/111#issuecomment-179898471
pal: The first paragraph needs to change 'conforms to' to 'uses' or equivalent.
nigel: I'm not sure the second
paragraph addresses the multiple profile indication issue
either. It's random which
... profile the processor will choose.
pal: It shouldn't matter which is chosen.
glenn: But the document may be lying and not any of the signalled profiles.
pal: But that's off the reservation.
nigel: My concern is that if we allow a random choice then it's possible that the presentation may be different depending on which profile is chosen, and that's a random choice so we don't achieve interoperability.
atai: There's no way to signal preference so I think what Pierre says is right.
glenn: Looking at "If one of the
resolved profile is a profile supported by the Processor, then
the Processor SHOULD process the document instance according to
the resolved profile."
... and one of the profiles is TTML1 and the processor chooses
that then we've jumped outside the intent of this
material.
... The algorithm that I proposed previously always chooses one
of the IMSC profiles or undefined. I'm not happy that
... this proposal is allowed to produce a different profile
that's outside the scope of this context.
pal: I don't want to be bound by IMSC if there's something else better that my processor can do later.
glenn: That's outside the scope
of this. Say for example that the document claims TTML2 and
IMSC-T and I choose TTML2.
... Now we're outside the IMSC processing space.
... The intent is to work within the IMSC processing
space.
... We could change to "If it chooses a non-IMSC profile then
this specification no longer applies" then that would address
my concern.
nigel: My concern is if
presentation would differ depending on the chosen profile.
Consider a document that signals
... both IMSC-T and EBU-TT-D. Would it make a difference?
pal: I'll take the ball on this. Can we discuss after this meeting.
nigel: We need to spend some time
on PR planning too.
... I'll leave the call open so the conversation can
continue.
pal: What are the criteria?
tmichel: Firstly to meet the PR
exit criteria. Glenn's recent input is very good news because
now all the tests have
... two implementations passing so we have fulfilled 100% our
CR exit criteria.
... Furthermore Glenn says that early March he will provide
another implementation so that could be considered as
<plh> https://www.w3.org/2015/Process-20150901/#rec-pr
tmichel: a third independent
implementation. Anyway we are already fine. Then we have to
wait for the end of CR
... which is set until Feb 28 I think. We cannot move to PR
before early March.
pal: And we have to resolve issues.
nigel: Don't we also have a requirement to resolve issues?
plh: Yes there is always a
requirement to resolve issues, but you can always make the case
to the Director if you demonstrate
... that the issue doesn't have to be addressed.
pal: The goal in my mind is to resolve or defer all issues.
nigel: +1
plh: You guys already have plans to work on IMSC 2 so you might decide to defer for the sake of the timeline.
pal: Yes we've done that already in the past.
plh: Another consideration is
normative dependencies. I guess you don't have a problem but
the Director will look
... at those and how stable they are.
pal: I think we're good on that.
tmichel: That's clear.
pal: Any objection to moving to PR on Feb 28th or as soon as possible after?
nigel: Do we not need to issue a new CR depending on the resolution of the issues?
glenn: That's up to the group. I'm probably going to be happy with not doing a 4th CR but incorporating into a PR.
plh: If you make substantive
changes you won't have a choice - because of the patent
implications then you have to move to a new CR.
... There's a way to prevent the call for exclusions from
getting in the way via your AC rep.
... As it is today the Director will force you to wait until
the end of the Call for Exclusions at the end of March.
pal: So you're saying that we cannot transition to PR until eof March?
plh: The Director could decide to
start the PR review e.g. mid-March, knowing that the CfE would
run out before the
... AC has to give the final answer. So I would not worry too
much about that. The CfE is likely to end before the PR.
... If you get every single AC rep of this WG to waive their
rights for exclusion then you can skip it for a new CR.
pal: I'd like to set a goal for us to make a concerted effort to make resolutions that are not substantive changes.
plh: I agree that the perfect is the enemy of the good-enough.
pal: I want to clarify that if
there are bugs we should definitely fix them but I'd like to
encourage us to make an effort
... to try to move towards PR at the end of Feb and if we hit
an insurmountable object then we'll deal with it.
david: I just need to bring in our perspective. There are other groups working on other standards. We're working really
<atai> +1 to what pierre said
david: hard to achieve a unified
standard, so if this splits then the industry that's waiting
for us will move on and we'll
... end up with fractures, not what we want, a unified subtitle
specification.
... Netflix wants us to get IMSC 1 adopted as soon as
possible.
mike: I think the same can be
said from ATSC and CEA/CTA. I think it's really important that
this work advance,
... although don't do anything unnatural. This ought to move as
reasonably as expeditiously possible to Rec. It's
... growingly inconvenient that this isn't published.
... Just echoing my colleague from Netflix there that we need
to get to publication.
<inserted> nigel: It seems that we're all in agreement that we want to publish as soon as possible.
glenn: I just wanted to indicate
that as far as I know none of the current issues involve a new
feature. They are
... semantic clarifications. In the past we have considered
those to be non-substantive.
nigel: We're out of time so I'll adjourn now. Thanks very much for a very productive meeting everyone. [adjourns meeting]