See also: IRC log
<scribe> scribe: nigel
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.
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: 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.
Nigel: We should defer discussing this.
Pierre: Maybe a public document would help also.
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> 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 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.
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.
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> 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 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> http://www.w3.org/AudioVideo/TT/tracker/actions/507
Nigel: I link from the agenda to
http://www.w3.org/AudioVideo/TT/board/
... Has anyone here ever followed that link and looked at
it?
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.
github: 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.
github: 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
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.
Nigel: Thanks everyone, we've done what we could on the agenda. [adjourns meeting]