See also: IRC log
<cyril> scribe: Cyril
nigel: I've looked at the issues
and Glenn does not seem to have update the issues
... there are still 2 PR: his and mine on his
... Mike nothing to add on that
mike: no I kind of lost track of what was going on
nigel: I noticed something that
relates to the RTP
... the codecs parameter specifies + and |
... but it references processor profile combination in
TTML2
... I've added issue #62
... it seems we can't make progress without glenn
pierre: is anything blocked here?
nigel: yes
... we should have published an update of the profile registry
regarding the publications on Nov 8th
pierre: IMSC1.1 is there in the editor draft
nigel: but not in the published
one
... we should be really trying to update it to make sure it has
the correct set of profiles
pierre: Mike, what do you need to get this published
mike: I am not the editor
anymore
... because the document has turned into many issues and not
the simple document I thought I would be editing
pierre: people care about the
list only
... can we keep it simple
nigel: yes, but glenn does not
seem to have this view
... and glenn is the only editor
pierre: we should revisit in a month and possibly change strategy
nigel: straw poll, does anybody else share my view that it is important to publish
pierre: yes, I thought this has been publish
cyril: yes
pierre: if it's a resource
isssue, I'm willing to take a stab at it but would simplify the
document a lot
... the table that really matters is 4.1
... all the rest of the text is really not useful
... especially if it causes issues
nigel: there is consensus that we
should get this done
... I'll mark this item on the agenda in 2 weeks
cyril: I think we should be
stronger
... if there is no update in X weeks, we should change strategy
and editor
nigel: how many X is?
cyril: I would say X=2 weeks with a possible extension
plh: my philosophy is: if the ED is better than TR, publish a new version no matter open issues
pierre: I agree with cyril
nigel: ok works for me
nigel: no update this week
<inserted> scribe: plh
Cyril: not clear how we're converging here. We had proposals and ideas, but how do we decide to move forward?
<inserted> scribe: cyril
cyril: not clear to me how we turn reqs into text
nigel: if WD is 1st of June/July, the first thing to do is to write explainers
cyril: I fear that writing explainers will delay the spec
nigel: if you want to go and propose text go ahead
pierre: in general, whoever
submitted the requirement is on the hook to provide the first
pass text
... until that happens, nothing can happen
cyril: clearer now thanks
... what about modularization
... should the proposed text be in the form of a module
nigel: if you think the text you
want to propose fits in a module, then yes propose it as a
module
... I'm happy to schedule time in the agenda for early
discussion
... if any group steer is heplful
<plh> https://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/
plh: do you mind if I retire the
UC and Req for TTML1
... right now it appears in the page of W3C
... I want to say this document is only here for historical
purposes
nigel: TTML specs reference it
plh: if you think it still matters, then I won't change it
nigel: yes we reviewed it
plh: ok, then I won't touch it
nigel: we discussed it last
week
... there has not been any update
... but the ongoing work will fix the current issues
... the new IANA section will say
<plh> https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/
nigel: W3C consideration sections
will disappear
... and IANA section will say "No IANA action" and the
duplicate media type registration text has been removed
mike: do you want to at least make a note that the registration details are in the W3C
nigel: yes it is somewhere else in the document
mike: oh I would put it here
nigel: it's in section 7
mike: odd location, but ok
nigel: the other change is around
the codecs parameter in the SDP
... we will say "shall be present" and mention processor
profiles
... I'm planning to use the profile combination logic of
TTML2
plh: what was the incentive to copy the IANA registration
nigel: we will remove it
gkatsev: I've been working on it,
submitted 2 PR to WPT
... just approved
... one fixes the preferences for line start and line end
... implementations were correct
... one for the references for white space pre
... the rendering tests go up to 81% completion
... the big thing on which I'm working now is region
... unfortunately, the collision avoidance tests are not
passing
... difference of implementation
... Chrome only does it in some cases
... snap-to-line is true
... the tests we have use snap-to-line false
... some browsers like Firefox also implement it but not
according to my reading of the spec
... you should choose the one above the cue first
... I can raise issue against browsers but not sure it will be
fixed soon
... and that would put the IR at risk
pierre: I'd love to pick your
brains on this topic
... it is really a part that I find weird and confusing
... the author specifies a position but not completely
... I think it's a pretty complex algorithm
... but the author should have complete control over
position
... collision avoidance should not be in the spec
gkatsev: looking at the test it seems to have been even more complicated
pierre: I'm not surprised that
implementations do different things
... one option is to remove it and say collision avoidance is
up to the implementation
gkatsev: there is an
accessibility issue
... you want to always show the caption if you can
... maybe on snap to line false we could remove that
pierre: I don't dispute the
overall goal
... it's ok to put that burden in the implementation rather
than in the spec
... I haven't seen cases with multiple tracks
... maybe forced but it's mutually exclusive with subs
gkatsev: I looked at WPT.fyi
tests
... it seems that the API passing tests jumped from 80% to 90%
and so they are up to fixing things
... one question: assuming WebVTT is removed from the
charter
... what are the options for WebVTT going forward?
pierre: have we eliminated just
trimming the spec
... to match what implementations do?
nigel: not sure we have time because that means publishing CR
pierre: if that were the strategy, it would help scope the charter
plh: republishing the spec by just listing features at risk, I don't see why it would be long
nigel: just based on experience
plh: it's not like the charter is ready to go in a month
nigel: the draft to review in march
plh: if we want to take the time,
we have the time
... but if nothing happens until now and the time the charter
goes to AC
... I will oppose mentioning WebVTT in the charter
... and it would simply remain in the community group
pierre: going back to what drove
having both WebVTT and TTML in the same group, is because
having them in two separate groups would have been worse
... putting browsers in the path of publication is not a good
idea because that is out of our control
... is there an appetite and interest to trim the spec to match
what is done today
nigel: there is not a single
simple answer to that
... it depends what would be removed
... for example things that are needed to meet FCC reqs would
be a problem
pierre: what do you think of trimming?
gkatsev: probably possible
... but removing things like region is very bad
... it's needed for FCC compliance and accessibility
pierre: it's even worse to have
something that does not match reality?
... for example ISMC1 did not support Japanese, but IMSC1.1
does
... it's better to have a first spec that reflects reality and
then have a second version
gkatsev: maybe that's
better
... I'm not sure
plh: you can branch the current
spec
... and do what pierre is suggesting
... you keep an ED with everything to start a v2
pierre: what is bad is having specs that are meaningless
gkatsev: maybe that's the best goal
plh: I think you should have asap
a list of features that could be marked at risk
... for review
... that is assuming that trimming would not take months
... and based on the IR would go to PR quickly
... we can even publish WD for v2 before v1 is published
gkatsev: that sounds like the best course of action
plh: the draft now matches the template
nigel: I have raised 3
issues
... 34 to 36
... 34 is to update regarding TT Requirements
... specifically live contributions and audio profile
... 35 is about modularization
... to make it clear that deliverables will be modules
... and to allow the group to decide which module will be on
the rec track or not
... 36 is a placeholder for WebVTT
... I think that is the scope of what needs to change in the
charter
... let me know if anything else needs to change by raising an
issue on the repo
<nigel> Draft TTWG Charter repo
<plh> https://w3c.github.io/charter-timed-text/
nigel: my timetable is to update the charter in the next weeks, except WebVTT
nigel: pierre received some
material from Fox
... that would be useful
... not as test but generally useful
pierre: Fox have put 2 test reel,
one for IMSC 1 text, IMSC 1 image, IMSC 1.1 text and
image
... it's IMSC documents and associated video and render
... this is not a unit test, not covering all variations
... but covers several reasonable variations
... IMSC 1 and IMSC 1.1 unit tests are not good sample
materials, missing video and sync
... that test material is really good complement to the IMSC
unit tests
... they've offered it to W3C
... it would be more valuable if hosted by W3C
... available under BSD licence
... my recommendation is for W3C to accept the offer and host
the content as part of the WG work
plh: my initial reaction is to
say no because it's already hosted on GH
... you will need to convince me
... why should we do it for this WG?
... do we need to insure maintenance
pierre: a member of the WG told
me their lawyers have cleared using materials from W3C not from
general GH
... even if the different site uses BSD
... another reason is for W3C to bring more people to W3C
... because the reel is of good quality
... on the maintenance the folks at Fox intend to maintain it
because they use it
... so the work by this group would be minimal
plh: I don't care if Fox maintains it, I need commitment from the group (it may be delegated to Fox)
pierre: I'm happy to commit to that
nigel: if someone is implementing
IMSC they need to find this resource
... we also have a wiki page and we could add it there
... I'm not sure what the right place in W3C is
... maybe MDN could also be a good place, for developer
guidance
pierre: linking from MDN would be a good thing but this does not solve the license/lawyer issue
cyril: I think this is important to have this test in W3C space because this is testing video + IMSC and it is the first
nigel: a lot of people have done it
pierre: yes but no one has made
it available to W3C
... HbbTV has nice tests apparently but they are not
available
... I think the wiki is fine
plh: why not create a separate repo
pierre: i'm fine with that too
nigel: we'll try to resolve offline. I don't have objections
plh: I'm happy to have the group
adopt those tests
... without the WG support I cannot take it
nigel: does anybody have an
objection to W3C hosting it?
... seems not
... then plh you can go ahead
plh: ok I'll follow up with Pierre
nigel: I added another AOB
... you have a poll in your inbox
... as to how we get to meet in september
... please reply
<nigel> Poll
<nigel> scribe: nigel
Nigel: Thanks everyone, apologies for running 10 minutes over. [adjourns meeting]