See also: IRC log
<scribe> scribe: nigel
Nigel: Today, I don't think we
have anything to discuss with TPAC today;
... I'd like to start running the TTML2 Wide Reviews to see if
we have any easy dispositions.
... And we agreed last week to discuss publication of FPWD of
IMSCvNext
... And we have had some other issues raised this week on
TTML1/2.
Mike: Request to cover backward compatibility issue in TTML
Nigel: Ok
... I'm not expecting David to join to discuss WebVTT review
today.
Thierry: I've had no confirmation.
Nigel: In that case I think we
have a full agenda.
... Any other specific points to cover?
Group: nothing else.
github: https://github.com/w3c/ttml2/issues/458
Glenn: This may be a duplicate of #442 - anyway they are related.
Mike: It's hard to summarise from
the issue - lots of opinions, not necessarily harmonious.
... It boils down to how we make IMSC vNext reference TTML2 or
TTML1, since we need
... a safety net for presentation processor conformance for
IMSC 1.0.1.
... These things are all intertwined. Fundamentally we started
out with what we are doing
... in IMSC v1.1.
Nigel: Pierre recently made the
comment that the presentation processor differences
... between TTML1 and TTML2 are already proposed for TTML1
Third Edition. If we do that
... would it address the problem for IMSC or just move the
problem somewhere else?
Glenn: I don't think we can add features to TTML1 to resolve all the differences.
Pierre: Trying to keep things
simple, the first step is to determine if we all think that
the
... goal of having TTML1 and TTML2 be consistent on shared
features is a good idea. Then
... we can figure out how to make that happen.
Glenn: I agree with that as a
default scenario. We could probably add a statement to the
current
... section on backward compatibility that says its an
objective to achieve that modulo
... explicit variations or exceptions.
Pierre: Anyone think it's a bad idea to have that as a goal?
Mike: No, and that's where I thought we ended up last week.
Andreas: I think it's important
to make it mandatory to state this objective in the spec.
... People will look for normative statements, otherwise it
won't help much.
Glenn: It's different stating the
objective to making a mandatory requirement on
processors.
... We should separate those.
Nigel: I think there is a problem
if we let edge cases drive specs, and I particularly
don't
... want us to be held back by previous specifications and be
unable to make improvements
... if we find them.
Cyril: Are we allowing for specific signalling of TTML2 behaviour?
Pierre: This is only for features
that TTML1 and TTML2 have in common.
... The question is if the high level goal is for parity of
processing, as a high level
... principle, then we can come to the details later.
Nigel: My understanding is this
is driven by a desire for identical presentation
processor
... output, so the details become important. I don't think that
the general guiding principle
... is controversial, and it's easy to agree with.
Glenn: There are layers that
affect every feature - it's not simple than just talking
about
... individual style features.
Pierre: It would be bad if TTML1
and TTML2 compelled implementations to end up with
... a different computed font size on an element due to
differing inheritance rules.
Glenn: I recall lineHeight and ongoing discussion of this in TTML2 vs TTML1.
Pierre: That's my point - these
should be aligned.
... Again, it's the normative statements that it's important to
make consistent.
Glenn: We made some explicit
decisions about lineHeight="normal" - we shouldn't go
back
... to those decisions.
Pierre: I'm just asking about the general principle.
Andreas: The rendered outcome of
a document only using TTML1 vocabulary should
... generate the same outcome for TTML1 and TTML2 processors -
this should be the goal
... of our activity. It should be mandatory for processors.
Glenn: I certainly would not agree to that statement, in its entirety at least.
David_Ronca: From my perspective
the primary objective for TTML2 is a robust spec that
... will carry us into the future. Where its possible to be
TTML1 compatible we should be
... but we should not preserve ambiguous or poorly defined
features in TTML1.
Andreas: That's a core question - how much is backward compatibility needed.
Nigel: We have a mechanism via
the TTML profile registry for systems that use it to
request
... a specific processor type, and we should use the
flexibility that gives us.
Glenn: We have never had a
normative requirement to have different implementations
... produce the same presentation as a general statement. If
you throw out a lot of other
... variation axes, then you might say that modulo those
variations it should be close.
Andreas: Following the
discussions, maybe there are different business requirements
here.
... For our side, backward compatibility is a first priority.
We are in the middle of uptake
... and adoption of the spec so it's important that current
implementation is not blocked by
... a message that TTML2 is coming and may change it. That
gives the message "wait for TTML2".
... At least we want to avoid that and keep TTML adoption
ongoing including IMSC1 adoption.
Nigel: Good point - my statement
earlier was that in agreement with David_Ronca I think
... it is a stronger objective to produce a future facing spec
than a backward compatible one.
David_Ronca: Compare to video
coders. We have to be able to make fixes and correctness
... needs to outweigh compatibility. TTML2 implementations can
still be TTML1 implementations.
... It's just like encoders can still make AVC or HEVC. We have
to be careful. I don't know
... if there are specific cases where we need stability of
features, but if TTML2 gets it right
... and TTML1 gets it wrong then TTML2 should prevail.
Mike: Is there an example of this?
Pierre: I'm not aware of such a
thing, and ironically many of those bugs were discovered
... while implementing TTML1, so most have been logged as a bug
on TTML1 and fixed in TTML2.
... So my technical opinion is that the probability that we can
align the two is very high
... via TTML1 Third Edition.
Glenn: I would not agree - there
are specific things like displayAspectRatio that are
ambiguous
... in TTML1 but fixed in TTML2.
Pierre: That ambiguity would have
to remain in TTML1.
... The common features can be aligned.
Glenn: If it's simply a matter of
fixing prose (even normative) then I think we can
back-fill
... ambiguities that don't require new features.
Cyril: Why not deprecate ambiguous TTML1 features?
Pierre: Some of the ambiguities
are in the core layout and styling algorithms. So it's
not
... deprecating a features, just correcting an ambiguity in
TTML1.
Cyril: If it's ambiguous in TTML1 then noone can interoperably implement it in TTML1.
Pierre: This is core, basic things like lineHeight style inheritance.
Cyril: Two choices: either it has
been demonstrated interoperably, or it has not, in which
case
... let's deprecate the feature.
Pierre: You can't do that - you can't deprecate style inheritance.
Cyril: Has it been demonstrated interoperably?
Pierre: TTPE and IMSC.js implemented it the same way.
Cyril: Why not fix the spec to reflect it?
Pierre: Exactly.
Glenn: We cannot deprecate
features in TTML1. There is no requirement for rendering
... interoperability, though it may have been a goal for some
implementers.
Pierre: I agree with you Cyril,
we should make it work consistently.
... My suggestion is to fix it in TTML1 Third Edition. We could
conceive of other ways, but
... that seems like a straightforward way of doing it.
Nigel: I think if we can achieve
consistency by retro-fitting to TTML1 Third Edition that
makes
... it a lot easier, but does that work for IMSC 1.0.1 which
references 2nd Edition? Would
... that resolve the original IMSC compatibility issues? Would
it make TTML2 processors
... process say IMSC1 documents in an acceptable way?
Pierre: We have a lot of
resolutions in TTML1 GitHub issues reflecting TTML2 fixes,
and
... we should capture those in a TTML1 Third Edition.
... The next step is to update IMSC 1.0.1, to give those
organisations that care the opportunity
... to update their implementations to match the updated
specs.
... W3C can't compel implementers to reference a particular
version of a spec.
Nigel: I have no problem with
that - making TTML1 Third Edition aligned with TTML2
... so that TTML2 represents clean feature additions.
Pierre: I would like to go back to the general principle.
Glenn: If it's too general I might not be able to agree.
<pal> https://github.com/w3c/ttml2/issues/458#issuecomment-336022891
Pierre: I proposed the text in the issue above.
Glenn: I need to contemplate that
language.
... When you say "features that the specs share" that doesn't
address my point about layers.
Pierre: "given a document that contains only TTML1 syntax, a processor was compelled by the TTML2 specification to process it differently than it would have been compelled by the TTML1 specification."
Glenn: I don't agree with that,
the way it is expressed.
... A clarification question: in some of my commentary on the
issues I have pointed out
... that an implementor may implement a processor that adheres
to some subset of TTML1 or TTML2,
... so if your objective as stated could be used as a mandate
to require a TTML2 implementation
... to operate in a bug-for-bug compatible way with TTML1?
Pierre: W3C doesn't compel
implementors to do anything. Given a TTML1-only syntax
document,
... the processors should not yield a different outcome on
those features that they have in common.
Glenn: I could accept a general
objective - as soon as you start hinting at touching the
... conformance section the answer is no.
Pierre: So do you agree on the
objective of making TTMl1 and TTML2 consistent on the
... features they share?
Glenn: Yes, and we can add that language.
Andreas: Yes, that should be a
clear objective. It is also important to say in the text
that
... a TTML1 document containing only TTML1 syntax, then this
applies, but that if TTML2
... syntax is present then the outcome may be different.
David_Ronca: What's a document that shares TTML1 and TTML2?
Pierre: No, the document would contain only features in common, i.e. TTML1 syntax.
Andreas: [has to drop off]
Cyril: Maybe a different
perspective to the question: in terms of implementation, how
do
... you translate your design goal? To minimise the overhead of
implementing both TTML1
... and TTML2, or further, to reuse exactly the TTML1
implementation for a TTML2 renderer.
Pierre: That's not what I had in mind, though it would be awesome if one could do the latter.
Cyril: In the worst case
scenario, if I have an implementation that switches based
on
... document type then it won't make any difference.
Pierre: The goal is to avoid
completely different tests, code paths, authoring tools etc.
We're
... trying to make it easier for people with a limited amount
of resource.
SUMMARY: General agreement that there should be compatibility where possible, and that this may be achieved in practice by publishing TTML1 Third Edition being made compatible with TTML2 where practical.
Cyril: A practical question: did this begin with a question about the processing rules for tts:disparity present in an IMSC 1.0.1 document?
Glenn: It's not simply a matter
of the document using TTML1 features only, so we need to
handle
... more generally which rules to follow.
Mike: It is complicated, but we
need to be clear, so if e.g. ATSC adopts one or two TTML2
... features into TTML1-based IMSC 1.0.1 we need to be sure
that the act of doing that
... doesn't cause things to behave differently.
Cyril: We could avoid this issue
by back-porting the feature to TTML1.
... Apparently it doesn't require any other changes in
TTML2.
Pierre: Conceivably we could create IMSC 1.0.2 to solve disparity.
Glenn: We cannot add it to TTML1.
Cyril: OK that's fine.
... Are there any other features coming from TTML2 that may
land in IMSC?
Mike: ATSC may adopt luminanceGain.
Cyril: That would be a path to at least solve that issue practically.
Pierre: We could follow the same path as fillLineGap in IMSC 1.0.1, by creating 1.0.2
Mike: If that solves the problem it'd be fine.
Nigel: This feels like the moment
to mention that factoring out the style attributes into a
... separate specification altogether might be quite helpful,
separate from the other spec
... semantics.
Mike: Someone needs to draft the text that reflects this discussion.
Nigel: For the TTML2 spec?
Mike: I think that's the target.
Nigel: Glenn?
Glenn: I'll draft something and send it to the list for discussion.
Nigel: I'm happy to look at that and try to make sure it reflects this discussion.
Mike: [needs to drop off the call]
action-507?
<trackbot> action-507 -- Nigel Megitt to Add imsc vnext repo to agenda, board, github-bot etc -- due 2017-10-05 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/507
Nigel: That's all done, and the TT board has been updated, so closing.
close action-507
<trackbot> Closed action-507.
Nigel: Now what about the FPWD of IMSC 1.1?
Pierre: It's ready to go.
Thierry: There are a couple of issues to discuss offline.
Pierre: The pub-rules checker said it was okay.
Thierry: I'll send you what I've found, and then request publication for the 17th.
<pal> https://github.com/w3c/imsc/blob/IMSC1.1/imsc1/spec/ttml-ww-profiles.html
<pal> https://rawgit.com/w3c/imsc/IMSC1.1/imsc1/spec/ttml-ww-profiles.html
Nigel: Last week we made the proposal to publish this. Any objections?
Cyril: No objection, but I did
raise a few issues on the document, mostly trying to
clarify
... the relationship between this IMSC version and the previous
one. It's important that
... people understand with simple communications what are the
differences.
... Pierre has responded to the issues.
RESOLUTION: TTWG agrees to publish FPWD of IMSC 1.1
action-509?
<trackbot> action-509 -- Pierre-Anthony Lemieux to Propose liaison text for the imsc 1.1 fpwd -- due 2017-10-12 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/509
Proposed liaison text re: IMSC 1.1 FPWD
Thierry: Who do we want to send this to? Should we use the same list as for the wide review?
Pierre: Same as the IMSC 1.0.1 WR I would say.
Thierry: Okay I will dig into that and come up with the list.
Pierre: There's an MPEG meeting the week after next so it's important to send this soon.
Thierry: I will update the drafts and send the final one after publication.
Nigel: I notice there's a deadline for comments - why is that?
Pierre: It's arbitrary, just seems like a good idea.
Nigel: This isn't a call for wide
review so I don't think it's a good idea to set a deadline
for
... comments but it would be good to indicate the proposed
timeline.
Cyril: +1
Pierre: What about Wide Review in January?
Nigel: Why not!
Pierre: We could just notify that we've started work and invite contributions.
Nigel: Perfect.
Cyril: Yes, what about just dropping the "by 13 December 2017"
Nigel: +1
Pierre: I'll fix the "submits" typo too.
Nigel: I'll take the action to update this and respond.
Pierre: OK great.
<cyril> https://github.com/w3c/imsc/issues/263
github: https://github.com/w3c/imsc/issues/263
Pierre: Were you happy with the renders Nigel?
Nigel: Yes I think so.
Pierre: My proposal is not to
make any normative changes in IMSC 1.0.1 but to add
... informative text and those examples, as well as maximising
the chances of using
... roll-up harmoniously with fillLineGap, would resolve this
issue.
... It was not completely intuitive to me, but since
fillLineGap didn't exist before, just saying
... how to use it should work.
Cyril: Nigel you said line areas can be generated without `<br>`s?
Nigel: Yes, line areas can be generated by line wrapping.
Pierre: I agree with your interpretation Nigel, by the way.
SUMMARY: @palemieux to attempt to exemplify this without substantive changes.
github: https://github.com/w3c/imsc/issues/254
Pierre: I didn't understand this, but maybe the new examples for #263 will help.
Nigel: Maybe!
... I didn't understand either.
Pierre: If we get to a point ready to move past CR we will need to ping @r12a.
Cyril: A side comment - for rubys in TTML2 would fillLineGap apply?
Glenn: The presentation of the
ruby is an annotation on a line area effectively so it
would
... be simply covered by the line gap as well. The height of
the line gap would be predicated
... on the height of the line area, which would in turn be
predicated on any annotations and
... the space that they need.
Cyril: Would the line gap between the ruby and the base text be filled by fillLineGap?
Glenn: Yes it's part of the line area already. It's a bit like the dot on an i.
github: https://github.com/w3c/imsc/issues/253
Nigel: I see you asked @r12a a question, @palemieux, so I think we're just waiting for that.
Pierre: That's right.
github: https://github.com/w3c/ttml2/issues/460
Nigel: [describes call from yesterday that generated this issue]
Glenn: If we're talking about an informative note I don't see any issue there.
Nigel: Yes that's it.
Glenn: I'd probably say something
like it's motivated by smpte:backgroundImage and
... extended to make it more compatible with ... whatever.
Pierre: It's more than that.
Glenn: It is, yes.
Pierre: I think what Nigel said is it's important to state equivalence.
Glenn: It goes beyond smpte:backgroundImage
Pierre: But there's a mapping from smpte:backgroundImage.
Glenn: Yes that would be fine.
Nigel: Yes that's a fair
representation of the proposal.
... I think we need to say something like "The semantics of the
smpte:backgroundImage
... attribute may be achieved by [whatever the equivalent
is]".
Glenn: Recall that there are two
mechanisms in TTML2 - backgroundImage and image,
... serving different purposes, one for content, the other for
background styling.
... In effect backgroundImage in SMPTE was ambiguous about
whether it was for content
... or styling - I suspect both, but mainly for content.
Nigel: I think it is clear it's for content.
Pierre: It is intended to be content, that's established.
Glenn: It's not stated in the SMPTE spec.
Nigel: I thought you weren't
supposed to have text in an element with backgroundImage,
... which settles it for me - worth checking though.
github: https://github.com/w3c/ttml2/issues/461
RESOLUTION: HTML5 needs to be made an informative reference in TTML2.
github: https://github.com/w3c/ttml2/issues/462
RESOLUTION: SSML needs to be made an informative reference in TTML2.
github: https://github.com/w3c/ttml2/issues/463
Nigel: The normative status of
WebAudio may change in the future but we can make it
... informative for now I guess.
RESOLUTION: WEBAUDIO needs to be made an informative reference in TTML2.
github: https://github.com/w3c/ttml2/issues/464
RESOLUTION: No use is made of the XML 1.1 reference so remove it.
github: https://github.com/w3c/ttml2/issues/459
Glenn: That's a simple fix.
Nigel: Yes, I commented in support of this on the TTML1 issue too.
RESOLUTION: Add tts:displayAlign="after" to examples.
github: https://github.com/w3c/ttml1/issues/254
RESOLUTION: Add tts:displayAlign="after" to examples.
github: https://github.com/w3c/ttml2/issues/455
Glenn: I can see that the two
feature designators could be confusing. The
background-color
... was added in TTML2. Pierre has pointed out that
backgroundColor includes the same
... things as background-color pulled in, namely the block,
inline and region versions. I think
... the resolution is to remove background-color and possibly
add some text to #backgroundColor
... to say that it includes those as well, informatively.
Pierre: In TTML1 did #backgroundColor include those three things?
Glenn: Yes by implication but not explicitly.
Pierre: That was my conclusion
too. In that case I would file an issue in TTML1 to make
... that explicitly.
Glenn: I would do this as a note in TTML2 and TTML1.
RESOLUTION: Remove #background-color and add an informative note that it includes block, inline and region and raise an issue to do the same on TTML1 Third Edition.
github: https://github.com/w3c/ttml2/issues/459
Pierre: It would be good to change the examples also to put the timing on spans rather than p elements, in S.2
Nigel: +1
Pierre: That might avoid people
adding fillLineGap in a copy of the example and not
understanding
... why it doesn't work!
Nigel: Agreed.
RESOLUTION: In S.2 Modify the example to put the timing on span elements and separate lines with `<br/>` inside those timed spans.
Glenn: Next week I'd like to talk
about TTML2 issues #437, #438, #439 and maybe #435
... and possibly a couple of others that are editorial
fixes.
Nigel: Yes, I'd like to tackle some TTML issues next week.
Glenn: We could also discuss #428
and #429 which are about activeArea and fillLineGap
... making them the same as IMSC 1.0.1
... Then the other question in my mind is what we do with
namespaces...
Pierre: That's my proposal. I
don't disagree that it's unfortunate. In the future we
can
... maybe add new things directly into TTML2.
Glenn: Another possibility is in 1.0.2 change to tts: namespace?
Pierre: It would break
implementations that look for the existing namespace.
... This is less than ideal, but it will cause the least amount
of pain overall for implementers
... and users.
Glenn: I'm not suggesting that we
have a reference from TTML2 to IMSC, but that we
... incorporate the syntax identically and the prose to the
extent that we can.
Pierre: I agree with that proposal.
Glenn: Nigel where are we with #427?
Nigel: I've made a lot of
progress - the umbrella issue is #406, and #427 lays the
structural
... groundwork, and that's done in the issue-0406- branch..
Glenn: I would prefer to make the table row say "Derivation:".
Nigel: Okay, when you see it, it
might make sense. I'll remove the "(informative)" though.
... Thanks everyone [meeting adjourned]