- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 5 Oct 2017 16:20:01 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D5FC195F.4AF86%nigel.megitt@bbc.co.uk>
Thanks everyone for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/10/05-tt-minutes.html
Please note the proposal to publish a FPWD of IMSC v1.1 next week, and to publish the IMSC v1.1 requirements.
Minutes in text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
05 Oct 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/10/05-tt-irc
Attendees
Present
Nigel, Pierre, Andreas, Mike, Thierry, Glenn
Regrets
Cyril
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]IMSC vNext Issues
3. [6]SMPTE backgroundImage deprecation
4. [7]TTML2 Wide and Horizontal Review
5. [8]IMSC vNext FPWD
6. [9]TTML2 #454 Missing ruby attributes from list of
styling attributes
7. [10]TTML2 #440 Condition attribute missing in Core
catalog.
8. [11]Other TTML2 issues
9. [12]Meeting close
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: I haven't had confirmation of whether David or Silvia
will join, so we'll bump WebVTT
... down the agenda until they join.
... Today then we have IMSC vNext requirements, TTML2 wide
review comments, and
... then WebVTT review comments.
... Anything else to cover, or specific points to raise?
Pierre: I sent an email - suggest getting to FPWD of IMSCvNext
as soon as possible,
... hopefully by next week so that it can be in time for MPEG.
Nigel: OK got that for the agenda, anything else? I know for
TTML2 we need to think about
... review comment timing.
Pierre: I'd like to cover Mike's two IMSC issues too.
Nigel: I don't think there's anything to discuss re TPAC so
I'll drop it from today's agenda.
IMSC vNext Issues
Pierre: Mike brought up two issues: a) if all IMSC vNext
references should be to TTML2,
... and if TTML2 is in fact a superset of TTML1 and processing
a TTML1 document with the
... TTML2 processor will yield the same result.
... b) deprecation of smpte:backgroundImage - to me that was a
good exercise to try
... deprecating that.
github: [15]https://github.com/w3c/imsc/issues/258
[15] https://github.com/w3c/imsc/issues/258
Mike: I was concerned that the focus has shifted from being an
extension of IMSC 1.0.1
... to being a subset of TTML2 and those things aren't
necessarily incompatible but they
... change the risk profile, so I'd like the group to consider
the choice here. It may be that
... we have to reference both TTML1 and TTML2, but changing
everything to TTML2 when
... there's a risk that the processing would change.
Nigel: I've always thought that TTML2 is a superset of TTML1,
and I've never seen anything
... that made me doubt that.
Pierre: There's a related issue w3c/ttml2#442 requesting that
the scope of TTML2 is
... defined as a superset of TTML1. For example there are
changes to prose for style resolution.
Glenn: Something to bear in mind is that a TTML2 document will
be processed differently
... by a TTML1 processor and a TTML2 processor. But more
importantly if a TTML2
... processor is processing a TTML1 document then its incumbent
on the implementation
... to behave modally as a TTML1 processor. It's not completely
clear what we're talking about.
Mike: We need to make a fundamental decision that either IMSC
vNext is a superset of
... IMSC 1.0.1 or a subset of TTML2. Based on what Glenn just
said I'm really concerned here
... about replacing TTML1 references with TTML2 ones.
Andreas: I think this is really important, that IMSC vNext is a
strict superset of 1.0.1.
... The question for this superset in the next version of which
version of TTML should be
... referenced for already present features is not easy to
answer. If we change any TTML1
... reference to TTML2 that could be a blocker for adoption of
IMSC vNext because all
... implementers need to check everything that's referenced and
verify that their
... implementation is still compliant.
Pierre: I thought the goal was to make TTML2 a superset of
TTML1, but are you saying
... that a TTML2 processor would process a document differently
from a TTML1 processor?
Glenn: Not if it is processing it as a TTML1 processor.
Pierre: What has changed?
Glenn: Lots of things, I'd have to check. Looking at the
version number, treating origin and
... position if both are present - if processing as a TTML2
document it would use position
... in preference to origin.
Nigel: I think that's a different question - position would
never be present in a TTML1-only document.
Mike: But other TTML2 properties may be added to a TTML1
document, such as disparity,
... as has been adopted by ATSC. If the presence of that TTML2
attribute triggers different
... processing of the whole document than in TTML1 that would
be a worry.
Glenn: It may be that we need to think about this a bit more.
Pierre: I'm happy to back out the TTML2 references and replace
by TTML1 in IMSC vNext,
... or I'm equally happy to make TTML2 a superset of TTML1.
Glenn: It is a superset in that it supports the features. The
question is which mode is it
... operating in, either with the knowledge of some fixes
relative to TTML1, or if the author
... declares that it's a TTML2 document, and puts a version="2"
parameter on it, then the
... author has said that TTML2 rules should apply.
... I don't see this as a binary answer.
Mike: In the case of TTML1 vs TTML2 we can sort that out as we
go, but in the case of
... IMSC vNext it's fundamental. If the intent is backwards
compatible then that's a different
... thing to "it's compatible with some different behaviours".
Glenn: I agree
Mike: I'm aligned with Andreas that IMSC vNext should be a
superset of IMSC v1.0.1.
Glenn: It may be that when there is an identified difference, I
wonder if we can make a default choice without studying each
case.
... Absent of information, I would assume that a reference to
TTML1 would be a safer bet
... than simply adopting references to TTML2 across the board.
Nigel: How does rendering using CSS factor into this, given
that we're putting the mappings
... from TTML style attributes to CSS informatively into TTML2?
Pierre: If we want to continue referencing TTML1 for processing
behaviours but also add
... TTML2 features like ruby, then we will have to create new
extension features for that syntax. We
... can't reference the TTML2 features because that brings the
whole TTML2 processing model.
... For disparity it's not an issue but for something like Ruby
then it might be an issue.
Nigel: Adding something else into the mix here, we have an
intention to work on TTML1 Third Edition
... which essentially backports the important fixes to TTML1
Second Edition. Which version
... of TTML1 do we want to reference in IMSC vNext?
Pierre: Going back to Andreas's suggestion, if we explicitly
state in TTML2 that the
... processor should process TTML1 documents as TTML1 then we'd
be good right? Why
... can't we say that?
Nigel: I have no reason not to be able to say that.
Pierre: Can we say in TTML2 that a TTML2 processor should
process a TTML1 document
... exactly as a TTML1 processor?
Glenn: Yes, that's always been the goal.
... There are no blanket statements to that effect.
Pierre: Then we have the specific issue here that Mike has
raised - that ATSC allows
... tts:disparity to be used in a TTML1 document without
specifying ttp:version="2".
... Could one solution in the case of IMSC vNext be never to
use ttp:version="2" except when
... using a whitelist of features that are known to affect the
processing model. Or prohibit
... ttp:version altogether?
Andreas: A question for my understtanding for ttp:version - if
we have a TTML1 document
... and we add ttp:version="2" the rendered outcome of a TTML1
document would be no
... different from a TTML1 processor at the moment? That should
not have any effect on the
... outcome.
Pierre: The particular example that Glenn brought up is
position, if ttp:version="2".
Glenn: More substantively if there's no profile present then
signalling ttp:version="2"
... causes selection of a different default profile. If it is
missing then the default would be
... as in TTML1, the old DFXP profiles. However if
ttp:version="2" is present then it would
... substitute the TTML2 default profiles which bring in new
processor profile defaults.
Pierre: If ttp:version is absent, and a TTML2 processor
encounters a ruby element what does
... it do?
Glenn: It depends on whether it is processing it as a TTML1 or
a TTML2 document, independently of ttp:version.
... If it is processing as a TTML1 document then it might
ignore ruby even if it knows how
... to process ruby. That's an implementation choice. We can't
from a spec perspective
... mandate the implementation in terms of backward
compatibility in this regard.
Pierre: If we remove ttp:version and let profile signalling
completely drive processing then
... there would be no ambiguity.
Mike: An IMSC1.0.1 document could add all the vNext features,
and the processor might
... understand it, then the version becomes critical, because
you're explicitly telling the processor
... to do something different.
Pierre: In the case of IMSC vNext there would be a profile
identifier so version wouldn't be needed.
Glenn: I disagree. We changed the profile mechanism. The
processor needs to know which
... profile processing system is being used.
Pierre: The mere presence of ttp:contentProfiles signals that
the new system is being used.
... The processor can unambiguously identify which TTML version
it would be using.
Glenn: You're suggesting removing ttp:version and adding an
algorithm for deriving the
... TTML version being used. I don't see that as being any
different.
Pierre: I'm addressing the case identified by Mike that
everyone might start putting ttp:version="2" in the IMSC
documents.
Glenn: That's maybe something that IMSC vNext should say
something about but I see it
... as a different issue from what is in TTML2.
Pierre: TTML2 requires ttp:version="2" if any TTML2 feature is
used including ttp:contentProfile.
... That's what the thread has said.
Glenn: No you're overstating it. I said if an author requires
TTML2 processing they can
... specify it. They can still not do so. If they fail to do so
then it would still provide some sort
... processing dependent on the implementation. I guess the
question is what should TTML2
... say regarding documents without ttp:version that do use a
TTML2 feature. My response
... would be as an implementer, since the author hasn't said it
is required, I would derive it
... using other methods, for example seeing if contentProfiles
were present. I don't know
... what you can say about authors blanket putting ttp:version
in the document. Maybe add
... a big warning saying "If you put ttp:version="2" then that
may cause processing differences in TTMl2 processors compared
to TTML1".
Pierre: What will ATSC signal as the profile in documents with
tts:disparity?
Mike: There's no choice, just IMSC 1.0.1 with the extensions
and with no other signalling.
... I don't remember if we suggested explicitly stating the
profile.
Pierre: Yes, IMSC, absolutely.
Mike: Ok, but there's no version, or other profile and there
probably never will be. To the
... extent that IMSC 1 is deployed in the US, nobody believes
that the additions in IMSC vNext are needed.
... If the additions land somewhere else, in a different
country, what is an ATSC decoder
... going to do? I don't know, this isn't heading in a good
direction...
Pierre: Imagine an IMSC 1 processor - it would ignore
tts:disparity.
Mike: The ATSC processor would know what to do with it. It was
explicitly agreed by this
... group that an IMSC processor ignore attributes it doesn't
understand.
Pierre: Now the same document appears in a non-ATSC decoder,
but one that is IMSC vNext,
... and it is labelled as IMSC v1 and there's no profile, and
it has tts:disparity, are we trying
... to solve the case of what it does?
Andreas: Isn't the question if we can make IMSC vNext use TTML2
features in a TTML1 processor?
... If a TTML2 feature is used then the processor must be a
TTML2 processor.
Pierre: It's hard to specify that, is TTML2 processing required
whenever a TTML2 feature is encountered?
Glenn: Here's something to consider: a complicated thing was
introduced in HTML5 - is it compatible with previous
specifications?
... Probably not. Have implementers verified that it's
compatible with their own implementations?
... Probably not. It was just defined. We have a similar issue.
We have to go ahead with
... caution about changes that affect processing in older
processors. I don't know how we
... check that we don't break compatibility. It's not out
intention to break it, and I don't have
... a list where we have made that decision either.
Mike: I understand the analogy, I'm not sure it's a good one.
Nigel: It's hard to move from the abstract to the concrete
without any specific examples
... where a TTML2 processor has a significantly worse
presentation than a TTML2 processor
... for a TTML1 document.
Pierre: I'm encouraged by Glenn's response that there's no
intention to differ. Glenn, do
... you have any objection to making a blanket statement in
TTML2 that a TTML2 processor
... processing a TTML1 document should yield identical results?
Mike: Be careful of the language.
Glenn: TBD the language, but I have no reason to object to
doing so.
... The question is do we want to introduce extra language. I
think I added a compatibility section.
Pierre: I would add it up front in the scope so the objective
is clear.
Glenn: Putting that in the front matter should be okay. I'm
just going to find the section I think I added.
Andreas: [I have to drop off] I support what Pierre suggested.
It's a good opportunity to
... start the IMSC requirements and to keep the backward
compatibility, which means that
... a TTML2 feature being used in an IMSC vNext processor would
not change any TTML1
... features used in IMSC.
Glenn: I added §3.4 under conformance, and it has forward and
backward sections. It is
... marked as non-normative but says things along the lines of
what we're talking about.
Mike: The conformance is one angle - it's important that a
presentation processor also
... does the same thing.
... Currently all the language is about conformance of
documents as opposed to rendering.
... Let's work on the language a bit - I'll take a run at it.
Glenn: It's §3.4 in TTML2.
... I recall we had a look at this in the past for TTML2 too.
SUMMARY: Mike to study TTML2 §3.4 and propose any
modifications.
SMPTE backgroundImage deprecation
Nigel: We should defer discussing this.
Pierre: Maybe a public document would help also.
TTML2 Wide and Horizontal Review
Thierry: I went through the archives and verified all the
comments sent in are there plus
... I've added some sent as liaisons. They're all on GitHub.
Some issues don't need any
... processing - if they say everything is fine. I still put
them on GitHub so they will be on
... our disposition of comments. All the comments have a label,
open, pending, etc. When
... the issue status changes we will add a new label.
Nigel: Fantastic, thanks for that - a lot of work.
Action-506?
<trackbot> Action-506 -- Thierry Michel to Draft a wiki page
explaining our review and disposition steps and labels -- due
2017-09-21 -- OPEN
<trackbot>
[16]http://www.w3.org/AudioVideo/TT/tracker/actions/506
[16] http://www.w3.org/AudioVideo/TT/tracker/actions/506
close action-506
<trackbot> Closed action-506.
Nigel: There were a number of issues that said thank you, they
would look at TTML2 but
... not before 30th September.
Thierry: If you agree I would take the action to write to them
to say we will process their
... comments but they should send them ASAP after their
meetings.
Pierre: I recommend to do nothing, and process them when they
come in, and put them
... in a queue.
Thierry: I've had comments come in 6 months late in the past
and the Director still wants
... to take them into account.
... I want to add a bit of pressure.
Pierre: They know how this works, I would say nothing!
Nigel: I'm happy to do nothing - they've told us they will do
something and we should assume that they will do so.
... I just wanted to check if we want to explicitly extend the
deadline.
Pierre: I would not.
Thierry: I would not.
Glenn: I agree, the deadline has passed. I would not put those
in as wide review comments anyway, they're not comments about
the spec.
Nigel: The point at which we draw a close to the wide review
opportunity is when we
... have agreed to request transition to CR.
Thierry: Correct.
Mike: Would it help to track comments as late and put them at
the bottom of the pile?
Pierre: I like that, a priori put them at the bottom of the
pile unless we all see that it's a big
... issue.
Nigel: Okay this is all fine for me, thanks everyone, we don't
need to take any action at all here.
... We simply need to come up with a disposition for every
substantive comment.
Thierry: Some issues are marked as editorial - we should have a
type label for editorial vs substantive.
Nigel: That works for me.
... I think in the old tracker there was a flag for exactly
that.
<scribe> ACTION: Thierry Check if there are
editorial/substantive labels for TTML2 issues and add if not.
[recorded in
[17]http://www.w3.org/2017/10/05-tt-minutes.html#action01]
[17] http://www.w3.org/2017/10/05-tt-minutes.html#action01
<trackbot> Created ACTION-508 - Check if there are
editorial/substantive labels for ttml2 issues and add if not.
[on Thierry Michel - due 2017-10-12].
Nigel: Between now and next week please could everyone look at
the GitHub issues and
... propose any dispositions, so that we can start to agree
them in next week's meeting, or
... at any rate discuss them?
Glenn: I've already addressed a couple of TTML2 issues, so if
we can get resolution on those
... today then I would be happy to close something.
IMSC vNext FPWD
Pierre: I propose a 1 week review of the draft and the
requirements document, which go
... hand in hand, and I keep synchronised. If there are no
major objections publish as a FPWD
... and send a liaison informing them of the beginning of this
work and inviting them to provide comments.
Nigel: What's the URL of the thing we're discussing?
... I see that IMSCvNext is not on the master branch of the
imsc repo.
... Can we put IMSC vNext in a new folder so we don't get a
clash of URIs?
Pierre: I didn't do that because then I'd have to synchronise
IMSC 1.0.1 changes with
... vNext. Also we haven't got a name for it yet.
<pal>
[18]https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d979960981429
9e4b361cf/imsc1/spec/ttml-ww-profiles.html
[18] https://rawgit.com/w3c/imsc/6eafca943b2294d2d2d9799609814299e4b361cf/imsc1/spec/ttml-ww-profiles.html
Nigel: Given that we're not proposing a pure subset of TTML2 I
would propose calling this
... IMSC v1.1, especially since we seem to be targeting IMSC 1
compatibility.
Pierre: That's what I'm thinking too.
Nigel: In that case I think we need an imsc1_1 folder.
Pierre: I really would like to delay that as much as possible.
Once it's published on /TR
... it doesn't really matter where it is in the repo.
Nigel: It makes it really awkward to navigate though. When
would you move it to a different folder?
Pierre: I think it will become obvious.
Nigel: We're not really expecting any changes to 1.0.1
Pierre: Compare with software development - you'd maintain
different versions on different branches.
... Here all the tests, examples etc are going to be
substantially the same.
Nigel: The other thing you'd do is use release tags.
... Okay, Pierre, you proceed as Editor.
Pierre: Can you request a short name?
<tmichel>
[19]https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0
005.html
[19] https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html
Thierry: Yes I will. Just to let you know there's a new rule as
per the above link, and it
... would be worth Editors looking at this.
Nigel: This is a convention for Latest Version links, mainly.
... Thanks for the reminder Thierry, I had seen that and not
taken any action.
<pal> ttml-imsc1.1
PROPOSAL: Publish a FPWD of IMSC v1.1 with the short code
ttml-imsc1.1, based on the ED in the IMSCvNEXT branch
Pierre: Would you like me to propose liaison text?
Nigel: Yes please
<scribe> ACTION: pal Propose liaison text for the IMSC 1.1 FPWD
[recorded in
[20]http://www.w3.org/2017/10/05-tt-minutes.html#action02]
[20] http://www.w3.org/2017/10/05-tt-minutes.html#action02
<trackbot> Created ACTION-509 - Propose liaison text for the
imsc 1.1 fpwd [on Pierre-Anthony Lemieux - due 2017-10-12].
action-507?
<trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to
agenda, board, github-bot etc -- due 2017-10-05 -- OPEN
<trackbot>
[21]http://www.w3.org/AudioVideo/TT/tracker/actions/507
[21] http://www.w3.org/AudioVideo/TT/tracker/actions/507
Nigel: I link from the agenda to
[22]http://www.w3.org/AudioVideo/TT/board/
... Has anyone here ever followed that link and looked at it?
[22] http://www.w3.org/AudioVideo/TT/board/
Pierre: I have not.
Thierry: No.
Nigel: Does anyone use it?
Pierre: I didn't realise it existed
Nigel: The reason I ask is that if nobody uses it then I will
drop it; conversely I could maintain it.
Thierry: I think it's valuable. I did use it some times, I
recall, but I'd forgotten about it.
Nigel: Okay I'll update the board and continue with it.
TTML2 #454 Missing ruby attributes from list of styling attributes
github: [23]https://github.com/w3c/ttml2/issues/454
[23] https://github.com/w3c/ttml2/issues/454
Glenn: This was an editorial change, I've already fixed it and
updated the ED.
... I guess we can change the status of this with labels. It's
done.
Nigel: I see, there's nothing significant to review here -
Thierry do you want to apply the
... appropriate labels?
Thierry: Yes, it's spec updated and WG approved.
Nigel: I've assigned it to you Thierry.
TTML2 #440 Condition attribute missing in Core catalog.
github: [24]https://github.com/w3c/ttml2/issues/440
[24] https://github.com/w3c/ttml2/issues/440
Glenn: This is from Andreas and he's reviewed to say it looks
good.
Nigel: Okay I'm assigning to Thierry to update the labels.
Thierry: Once we have all three of: WG resolution + spec
updated + commenter agreement
... we can close issues.
Glenn: What if we cannot get agreement from the commenter, do
we have to leave issues
... as open if we have disagreement?
Thierry: We can close issues but it will red flag to the
Director that we will have to explain
... to the Director.
SUMMARY: WG approves, Thierry to update labels
Other TTML2 issues
Glenn: We haven't discussed XML, CSS comments etc.
Pierre: I would like to close those issues off, so can we
schedule a time to do so?
Nigel: Sure, if we cannot resolve it on the GitHub issue.
... We have discussed over the years some issues about time,
mediaOffset, and begin and
... end clipping, which I want to resolve soon too.
Glenn: Check if there are existing issues.
Nigel: Will do.
Meeting close
Nigel: Thanks everyone, we've done what we could on the agenda.
[adjourns meeting]
Summary of Action Items
[NEW] ACTION: pal Propose liaison text for the IMSC 1.1 FPWD
[recorded in
[25]http://www.w3.org/2017/10/05-tt-minutes.html#action02]
[NEW] ACTION: Thierry Check if there are editorial/substantive
labels for TTML2 issues and add if not. [recorded in
[26]http://www.w3.org/2017/10/05-tt-minutes.html#action01]
[25] http://www.w3.org/2017/10/05-tt-minutes.html#action02
[26] http://www.w3.org/2017/10/05-tt-minutes.html#action01
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [27]scribe.perl version
1.152 ([28]CVS log)
$Date: 2017/10/05 16:17:51 $
[27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[28] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 5 October 2017 16:20:27 UTC