See also: IRC log
<cyril> scribe: Cyril
nigel: Looking at the agenda, and
given Gary's regrets, we should probably skip the WebVTT
topic
... the other 2 topics we can discuss, even without Glenn
... live contribution
... and 3 PR or issues on TTML2
nigel: contribution in from
EBU
... 2 specifications of EBU-TT
... extending the EBU-TT profiles of TTML1
... and to specify web socket
... my proposal is to rebase those on TTML
... there is nothing specific about EBU-TT that is required to
make this live extensions work
... it does not use SMPTE time base
... it is applicable to TTML1 or TTML2
... EBU-TT is based on TTML1
... and I don't think there is feature of TTML2 that are
problematic
... so the question is to which spec to rebase to
pal: do you need a normative
reference to TTML?
... does TTML2 say that it's a superset of TTML1?
nigel: mostly
... yes
pal: you could always say both
TTML1 and TTML2
... or say conform to TTML1 and because TTML1 is a subset of
TTML2, you could add it as a note
nigel: if we base it off TTML2, and because a TTML1 document is conforming to TTML2, that would work too (maybe with a note)
pal: yes, that works too
... if you don't reference both, put a note to the TTML2
section about backwards compatibility
nigel: the scope of it is either
live authoring or streaming of prepared subtitles and
captions
... the source is an author or system
... the intent is not to define a distribution format
... the target is an encoder
... you can use CMAF for example as target format
... the approach is that you send several documents
... each one of which covers a period of time
... a subsequent document can temporally override a previous
document, either completely or partially
cyril: how do you know if it's too late?
nigel: if a particular interval
of time is changed after the encoder has already created output
for that period of time
... it's too late
... but if it's before, it can take it into account
... obviously, the real world periods of time depend on
deployment and delays
cyril: is it simply saying you
can send TTML documents on web sockets?
... or does it talk about ISD?
nigel: it doesn't mention
ISDs
... because TTML1 did not define an ISD syntax
... the format is agnostic of the transfer (websocket, tcp
socket ...)
cyril: what is the normative part?
nigel: the normative part is
resolving temporal overlap
... rules on defining effective begin and end time of documents
in the context of sequence
... the contributions have lots of explanatory text and
examples
... what should be the structure of this?
... have a small document with normative requirements,
small
... and a separate informative document that talks about real
world deployments and examples, as a WG note
... or to reproduce all the content in a new single
specification
... I would always make carriage over web socket a separate
document
cyril: I would prefer having the smallest normative document
pal: the ratio of
informative/normative is too high
... it introduces one new attribute?
nigel: 2 parameter attributes
pal: processing
requirements
... 2 pages should be normative
... the rest is use cases, requirements .... that should be
moved somewhere else
atai2: I would also support this
approach
... I would go even further and just have the edit vocabulary
with short descriptions
... and the system model/processing in a different
document
... the least amount of text would be helpful to get the basic
idea and how to implement it
nigel: we have an agreement
... I will try to create a small as possible normative
document
... and have additional explanatory documents
... to be published as WG notes
... We thank EBU for providing these contributions.
cyril: is there any reference to the HRM?
nigel: no there is no reference
to it
... it's unlikely to be a real world problem
... you could of course stress a system
... but only in that case you could exceed it but not in real
world content
... also HRM is a feature of IMSC not of TTML
nigel: can we deal with any of
them?
... relative profile designator, we need Glenn
... the topic on ruby needs Glenn too
... can we talk about region timing?
cyril: yes
<inserted> scribe: nigel
github: https://github.com/w3c/ttml2/issues/1073
Nigel: region timing is pretty complex, and there are no tests, right?
Cyril: I checked and couldn't find them, and neither could Pierre
Pierre: Nope, I couldn't
Nigel: Given the complexity of this I think it's something we should work on, or even deprecate the feature.
Cyril: It's used for IMSC Image Profile?
Pierre: That's the only place I've ever seen it used.
Cyril: How is it used?
Pierre: A div is selected in a
region and the div has the smpte:backgroundImage, and there's a
1:1 mapping
... between each div and each region.
Cyril: Why is the timing on the region and not on the div?
Pierre: I literally don't know. I remember seeing it once done that way.
Cyril: It's not a pattern?
Pierre: I don't think so. [checks
out the Fox content]
... In their example the timing is on div.
... I remember seeing this used once but I don't think it's a
pattern.
Cyril: That one has div timing
Pierre: Right
Nigel: There are subtleties
here:
... For example, the ISD synthesis rehomes body to a region
parent, but the body timings are not (I think)
... relative to the region's timings. Is that right?
... Therefore there's a potential intersection between the
active intervals of a region and content selected into
it.
... So what happens to content selected into a region outside
its active interval?
... Does it get temporally clipped? Or does the region's active
interval get extended?
... Pierre, you must have implemented this, but I can easily
imagine other implementers might get it wrong one way or
another.
Pierre: [looks at the imsc.js
implementation]
... It's pretty clear that my conclusion at the time was that
regardless of how timing was set on a region, if it was
not
... active then nothing else can be active at that time.
Nigel: So the region timing temporally clips its content?
Pierre: Yes. I think there was a
thread on this, I'd have to go back.
... This makes sense in the context of
showBackground="whenActive". That's one way to have a region
where
... the black background is only shown when the region is
active, and making that explicit.
Nigel: That does make some sense, yes.
Pierre: One way to set when a
region is active explicitly, especially in the US caption
style, is to have a begin and end
... on a region.
Nigel: You'd think that, however
the normative text on showBackground refers to content being
selected into it.
... So arguably even if a region is active, if no content is
flowed into it then showBackground doesn't happen.
Pierre: The way imsc.js does it
is it resolves timing completely separately for regions and
body. It applies the timing
... resolution algorithm separately to region and to body. So
it's the intersection model.
Nigel: That's easily testable, right?
Pierre: Right. I was stunned not
to find a test in the imsc tests, because I thought there was
one, but maybe no test
... ever made it to the test suite. I searched and couldn't
find any region with a begin on it.
... I really like the idea of adding tests.
Cyril: The related question is what to do on IMSC. I opened an issue to deprecate this feature in IMSC, w3c/imsc#473.
Pierre: In the grand scheme of
things it's not a big deal if the intersection model is used,
it's pretty easy to explain
... and straightforward. And it's implemented in imsc.js.
... One thing to think about is there are tons of other things
that nobody should use, like nested timing.
... Maybe one thing to consider is to at some point in the IMSC
lifecycle do a pass on everything that we think people should
not do
... because there's no use for it and deprecate all of them. It
would be weird to deprecate just that one.
Cyril: If you find other features to deprecate then fine, but we should give a signal and not let it linger.
Pierre: Why does it shock you, aside from the lack of tests?
Cyril: We don't implement it and don't see the value.
Pierre: That's true of other
things, right, like seq timeContainer, nested region reference
(e.g. nested divs with different region references)?
... I've not found any reason why anyone would do the latter,
which has serious consequences.
... I have my own personal list!
Cyril: We should go through that list. If people don't implement it, then let's be clear about it.
Pierre: My suggestion is if we
want to start deprecating things that are not broken but we
think are not useful and
... potentially confusing we should look at that. It's late in
this cycle.
Cyril: If it has never been tested you can't say it's not broken, right?
Pierre: I don't think that argument really works. We can agree it's not great to use.
Cyril: If you cannot rely on it because implementations don't agree, then either it's broken or deprecate it.
Pierre: TTPE and imsc.js might
actually work but that's not the right threshold.
... Just because they implement it doesn't mean it shouldn't be
deprecated.
Cyril: No, but if they don't agree then we should consider deprecating it.
Pierre: My point is there are a lot of features that go into whether or not to deprecate something.
Cyril: Exactly.
Nigel: The first stage is to create a test to see if the implementations agree or not.
Cyril: Yes
Pierre: I think that's a great
idea.
... I'm supportive of generating a list of features to
deprecate from IMSC but we might be late in this process to do
that.
Nigel: At least surfacing that list would be helpful even if we don't implement the deprecations until later.
Pierre: Totally agree.
Nigel: Does anyone want to create the tests?
Pierre: We can split the burden.
Cyril, if you want to create the tests then I can add them to
imsc-tests.
... I recommend you create a pull request against imsc-tests
and then I'll test them with imsc.js.
Cyril: Hmm, creating the tests when I don't support the feature!
Pierre: The primary ingredient
for deprecation is that nobody wants it.
... I'm not going to come back and say because you created the
test you want the feature!
Cyril: Yeah, I'll create the test.
Pierre: By the way you might prove it's broken, in which case we can deprecate it urgently.
SUMMARY: @cconcolato to create a pull request on imsc-tests adding a region timing test, @palemieux to run the test through imsc.js
github: https://github.com/w3c/ttml2/issues/1043
Pierre: Although Glenn is not here, I'm interested in the perspective of other members.
Nigel: I've been quiet up to now because I can see both sides and don't have a strong view.
Pierre: This isn't about the white space handling - we have agreement on that.
Nigel: Right, I think we should
be super clear about which style attributes should generate no
marks on the boxes
... generated by spans where ruby is container, textContainer
or baseContainer.
... I would do it like in your pull request Pierre, or by
refactoring the definition into a single place and creating a
special
... term for those kind of span.
Cyril: I like Glenn's pull request and Nigel's proposal too.
Pierre: This is a real point of
confusion because of the way Firefox handles it. TTML should be
clear.
... I'm happy to repeat the text or use a definition. I
actually started with a definition but didn't want another one
but
... I'm really happy to recast the pull request with a
definition, of a new kind of span, and use that.
... Thanks for sharing your feedback.
... I'll update my pull request by putting in Glenn's text
about linear whitespace etc.
Nigel: Glenn has already made it
clear he doesn't think the existing spec is for any marks to be
made,
... but I haven't seen anything traceable there. Did you say
your test only shows that in Firefox? What about Chrome or
webkit?
Pierre: They're so broken with
ruby that I don't trust them.
... Glenn's argument is that text decoration only applies to
terminal glyphs, but that's not always the case.
... I will update my pull request based on your feedback.
... Thanks.
Nigel: Advanced info, I won't be able to attend on May 30th.
Pierre: Regrets for me for next week.
Nigel: Thanks everyone [adjourns meeting]