W3C home > Mailing lists > Public > public-tt@w3.org > June 2018

{minutes} TTWG Meeting 2018-06-21

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 21 Jun 2018 15:41:51 +0000
To: W3C Public TTWG <public-tt@w3.org>
Message-ID: <D7518596.5F499%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2018/06/21-tt-minutes.html

Minutes in text format:


   [1]W3C

      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

21 Jun 2018

   See also: [2]IRC log

      [2] https://www.w3.org/2018/06/21-tt-irc

Attendees

   Present
          Nigel, Thierry, Pierre, Cyril, Glenn

   Regrets
          Andreas

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This meeting
         2. [5]TTML2 CR2
         3. [6]IMSC 1.1 requirements
         4. [7]Consider TTML feature(s) for rw/rh <length> units
            imsc#372
         5. [8]IMSC 1.1
         6. [9]tts:position should be allowed on region only
            imsc#366
         7. [10]CSS actions review
         8. [11]Meeting close
     * [12]Summary of Action Items
     * [13]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This meeting

   Glenn: [can only stay 45 minutes]

   Nigel: Thanks for letting us know.
   ... Any other time constraints from anyone?

   group: [silence]

   Nigel: Today we have TTML2 issues if there are any for CR2, and
   any comments to be
   ... raised on the CfC.
   ... I should also raise the way that we are responding to
   comments raised during the CfC period.
   ... I don't think we have anything on TTML1. Anything on IMSC?

   Pierre: There's one issue we ought to discuss, #372 re rw and
   rh, because you were surprised Nigel.

   Nigel: Yes, let's add that.

   Pierre: Also, based on feedback I've received I'm about to open
   another issue against the
   ... requirements for rubyAlign which we could usefully discuss.
   It's already there actually.
   ... Actually we already discussed rubyAlign so we don't need to
   cover that.

   Nigel: We have one action on CSS.

   Glenn: I have a couple of issues to discuss on TTML2.
   ... There are 5 pull requests approved pending merge.

   Nigel: Let's come to that, just doing the agenda now.

   Glenn: I have a couple of items on TTML2 to get to.

   Nigel: I don't expect anything on WebVTT. I haven't got a TPAC
   agenda item, but just to
   ... remind everyone registration is open.
   ... I've started to work on a list of topics to cover in a
   potential joint meeting with the M&E IG
   ... which I will share.
   ... Anything else for the agenda today?

   group: [silence]

   Nigel: Ok let's go.

TTML2 CR2

   Nigel: Status report: CfC is more than half way through and
   there are some pull requests
   ... that address comments received during the CfC period. I
   want to treat those as CfC
   ... review comments and merge the fixes for those soon, but
   alert everyone to the fact
   ... that is happening and encourage you to be aware when
   reviewing.
   ... We have 5 approved pull requests pending merge, and I would
   propose that we merge
   ... them as soon as possible.
   ... Any objections to doing that?

   Pierre: Not an objection, just confirmation that
   ... changes to the feature list are going to be treated
   editorially, so we can make those
   ... changes prior to PR?

   Glenn: I would support that.

   Pierre: I thought we had discussed it.

   Glenn: I think you could argue it both ways. The feature system
   is on the one hand a meta-feature
   ... in the sense that it is about features and it is not
   defining new features but labelling them.
   ... On the other hand the standard profiles are normative so
   every time we add or change
   ... one of the profiles files it is changing some normative
   text in the document. I would
   ... prefer to take your point of view.

   Pierre: I agree with your assessment.

   Glenn: If we do it that way then we should say that in the SoTD
   to give ourselves permission
   ... to do that, which could result in objections from external
   readers that we would have
   ... to deal with. We should raise that in the transition
   request.

   Nigel: The transition request has gone through but we can amend
   it.
   ... I'm not hugely comfortable with this.

   Pierre: If we are not comfortable with it there may be
   alternatives but we should talk about
   ... it because there's a significant risk that we may have to
   modify features and the way
   ... they are formulated, just because of the sheer number of
   them.

   Glenn: Changing the feature list is not adding or subtracting
   syntactic or semantic
   ... components of the specification.

   Nigel: Here's a test: if an implementation supported a feature
   and that feature definition
   ... was changed then it could cause that implementation to
   become non-conformant, so
   ... from that point of view it is a normative provision and the
   change would be substantive.

   Pierre: I agree.

   Glenn: I agree.

   Pierre: Then if we don't give ourselves that permission then
   what can we do?

   Glenn: We can move it to TTML2 2nd Ed. We could note
   informatively that we intend to
   ... make certain changes but that due to timing we were not
   able to do it in 1st Ed.

   Nigel: Previously we tried to make editions non-substantive in
   change.

   Glenn: It would have to go through the CR process again.
   ... I wouldn't be surprised if we don't have other normative
   changes given the large number
   ... of features.

   Pierre: I understand the rules as they're written right now,
   but this is pretty inefficient.
   ... Refactoring features is highly unlikely in practice to
   cause interoperability issues.

   Nigel: I disagree.

   Pierre: Can you point to such an implementation?

   Glenn: Back to the point about making implementations
   non-compliant, it depends on the
   ... implementation. If the implementation depends on the
   override route, the first processing
   ... step of construct effective processor profile, then the
   implementation can set it to
   ... whatever it wants. How many processors will not take that
   route?

   Nigel: We have to apply this rule to content conformance and
   that is more likely to be
   ... affected.

   Glenn: If you define a content profile and use it for
   validation and then add a new feature
   ... that could not have been prohibited but add that
   prohibition based on the new feature
   ... then that's not going to be a problem. If you change the
   semantics of existing designators
   ... then you may end up prohibiting syntax that was not
   previously prohibited.

   Nigel: If you're going to create the content profile mechanism
   then you have to allow it to
   ... be used safely.

   Glenn: Ok. Clearly we can make changes on the way to 2nd Ed if
   we go through a CR process.
   ... So going back to the question about practical issue? I am
   of a mind that it is very low risk
   ... in causing a practical issue.

   Nigel: That may be true, but it's not the test.

   Glenn: That's correct.
   ... If we have a consensus in the group we can present that.

   Nigel: Can I make a proposal that we add a bullet to the at
   risk feature list to notify readers
   ... that the definitions of feature designators may change. If
   we can do that for features
   ... and then make the substantive change at PR then I'm willing
   to see if we can do it for
   ... feature designators too.

   Glenn: I like it.
   ... Just adding a #profile-version-2 bullet to the at risk list
   might do it.

   Nigel: My understanding is that the at risk list is for
   features that can be dropped but not
   ... changed.

   Thierry: You're only allowed "drop".
   ... If you change a feature and it is substantial then you have
   to issue a new CR.

   Nigel: Pierre, are you concerned that you won't be able to
   complete a review of the TTML2
   ... feature designators during the review period?

   Pierre: I expect to be done ahead of next week.

   Nigel: In that case do we really need to worry about this?

   Glenn: I'd be satisfied to not change the at risk list and if
   we get a request to change then
   ... use the standard route to deal with it, i.e. to add
   informative text until the next edition.

   Nigel: I think that might be the best way.

   Glenn: We already have a changes document. Eventually we will
   probably have a new section
   ... changes from CR2 to PR and by definition they would all
   need to be marked as editorial
   ... but we could prominently point out editorial changes of
   this type, that are warnings to
   ... the reader that something we found will be changed in the
   near future.

   Nigel: Sounds like a good idea to me.
   ... I think we've circled round on this one and concluded that
   we will take no action.
   ... Any other views?
   ...
   ... Ok that's a 'no' so let's move on.
   ... This arose from the question about merging approved pull
   requests now. Any other
   ... questions or points on that?
   ...
   ... I'm taking silence as assent, so Editor(s) you can go ahead
   and merge the following pull
   ... requests: #836, #842, #843, #844 and #845.
   ... Noting that 843, 844 and 845 are labelled "substantive".
   ... Any more issues from you on TTML2 Glenn?

   Glenn: No.

   Nigel: The other point I wanted to raise is that we're making
   change to the document
   ... during the CfC and it would seem fair to allow it to
   stabilise. Are there any other
   ... pull requests expected?

   Glenn: There's one for issue 830 and the other for 834 which
   tweaks the base-related
   ... features. It is going to involve adding a new feature
   called #base-general. To make it
   ... consistent with other definitions and the ability to
   prohibit the more general use of #base

   Nigel: There are several editorial issues too.

   Pierre: Glenn and I discussed 846 and realised it hadn't been
   opened as an issue yet.
   ... I expect to be done tomorrow with my review so hopefully
   we'll be very close tomorrow.

   Nigel: Can we set a target to merge all the pull requests by
   the end of tomorrow?

   Pierre: Monday is more realistic.

   Glenn: I agree.

   Nigel: OK
   ... I issued the CfC on Wednesday 13th June, so end of Tuesday
   is the end of the CfC.
   ... So that gives 1 day for final post-pull-request-merge
   reviews before the end of the CfC.
   ... It's pushing the limits a little!

   Glenn: Starting on the 26th, if we finish merges on the Monday,
   I plan to do the normal
   ... pubrules and link checking which requires some minor tweaks
   which will require at least
   ... one pull request. I'll need someone at hand to approve
   those quickly so I can merge them.
   ... By the end of the 27th I need a package to send to staff
   for upload for CR2 if it is going
   ... to be published on the 28th.

   Thierry: The webmaster usually needs 2 days.

   Glenn: If we get that done on the 26th would that be adequate?

   Thierry: Yes it would be better at the end of the 26th if you
   can submit a package then
   ... I can take care of it late on the Tuesday or early morning
   Wednesday my time.

   Glenn: OK I'll make that a date then. I'll probably start doing
   the pubrules and have it done
   ... by the 25th as well.

   Nigel: That'd be good, thank you.

   Glenn: I'll need help from another committer who can approve
   requests over the weekend.

   Pierre: I plan to be around.

   Nigel: With notice I will be able to also.

   Glenn: If you could be able to check your email once a day
   between now and Monday that
   ... would be adequate.

   Nigel: Ok, with the proviso that if there's anything strange or
   unexpected or complicated
   ... then I will probably block merging. We really need to ramp
   down the significance of
   ... any changes from now on!

   Pierre: +1 with a proviso that we need to avoid substantial
   changes. But if there is a real
   ... blocker then it is not a reasonable answer to wait until
   2nd Ed. especially if everyone agrees on the solution.

   Nigel: If something substantive does come up that needs a
   significant change then I would
   ... rather wait a few more days now than wait until 2nd Ed.

   Pierre: Exactly.

   Nigel: Included in the scope of those changes to be merged as
   soon as possible is the
   ... branch with the updates to changes on that you were working
   on Glenn.

   Glenn: I can get that done by tomorrow.

   Nigel: Then we can modify the transition request to point to
   the ED.

   Glenn: [has to drop off the call]

IMSC 1.1 requirements

   Nigel: I think we had one issue to look at, #372.

Consider TTML feature(s) for rw/rh <length> units imsc#372

   github: [14]https://github.com/w3c/imsc/issues/372

     [14] https://github.com/w3c/imsc/issues/372

   Nigel: My understanding of rw and rh was that they are
   beneficial especially with fontSize.

   Pierre: Today you can achieve the same effect using `c`. It's
   not pretty but you can achieve
   ... that effect.
   ... We have discussed those requirements for many months and
   nobody has suggested we
   ... add them. I think it is in the "too late" category. I'd be
   more sympathetic if there were no
   ... other way to achieve it.

   Nigel: Why are we too late?

   Pierre: We are about to go to CR2 and there's a cost for
   supporting container related dimensions.

   Nigel: A syntactic cost, given that the semantic is already
   feasible.

   Cyril: It's not because it's been there for months that we
   cannot change it. We have to
   ... acknowledge we have mostly been working on TTML2 to finish
   it, so we should give
   ... ourselves some quality time to look again at the
   requirements for IMSC 1.1.

   Nigel: +1 My time has been taken up by TTML2 mainly and I would
   like that opportunity.

   Pierre: There's a cost to implementing it.
   ... So far nobody has made the argument why it is required.
   Don't get me wrong, I think
   ... it might be useful, but just nobody has explained why it is
   required.

   Nigel: From my perspective the requirement is driven by the
   errors that I see when QAing
   ... TTML documents that I see, where people get the %
   calculations wrong.

   Pierre: I don't expect anyone to adopt it.

   Nigel: If it is absent from IMSC 1.1 then hypothetically EBU
   could not adopt it say in EBU-TT-D.

   Pierre: If there were a liaison from EBU saying they wanted it
   then it would make the argument,
   ... but there is not one.

   Nigel: I'm making this comment from my own experience, that c
   units cause difficulties
   ... and we should move towards rw and rh.

   Cyril: I don't want to take a closed decision now - I need time
   to think about this.

   Pierre: If this is needed then it should be raised as an issue
   against the requirements.

   Nigel: Arguably Stefan has raised this issue on the wrong repo.

   Pierre: Cyril, if Netflix is interested in adding rw and rh I
   ask that you do it super soon so
   ... we can get it in and get it done.

   Cyril: I don't think we need it but I will cross check today or
   tomorrow.

   Pierre: Super. Nigel, if EBU has IMSC 1.1 adoption on its
   roadmap and has strong feelings
   ... about rw and rh it would be good to know.

   Nigel: I am not expecting any such statement.

   Pierre: Or from anyone who plans to use IMSC 1.1 and has
   substantive input, now is the time.

   Nigel: I've raised w3c/imsc-vnext-reqs#33 for this.

   SUMMARY: Feature discussed, different viewpoints currently
   remain, requirements issue raised.

   github-bot, end topic

IMSC 1.1

   Pierre: I'm making great progress and should have something to
   present for review later
   ... today, refactoring the features table to match TTML2 and
   fix some of the outstanding issues.

   Nigel: Great! Did you have a view on the labels and colours
   question?

   Pierre: Yes, I really liked where you and Stefan ended up. I
   plan to implement something
   ... along the lines of what you have, putting the background
   and rounded corners on the
   ... permitted/deprecated/permitted-deprecated label itself.

   Nigel: Looking forward to seeing that.

   Pierre: Thank you for doing all the prototyping work, that
   makes it a lot easier.
   ... I plan to address that at the last moment when we are happy
   with the features table.
   ... Can we talk about #366?

tts:position should be allowed on region only imsc#366

   github: [15]https://github.com/w3c/imsc/issues/366

     [15] https://github.com/w3c/imsc/issues/366

   Pierre: My impression is that we have trained people not to use
   origin and extent on content
   ... elements. Certainly in IMF and ATSC we have trained people
   not to do it.
   ... imsc.js and TTPE and EBU-TT-D does not support it, so in
   fact I think the trend has
   ... been the opposite, that we have reiterated that you cannot
   do it. We have been saying
   ... that for the past 2 years and I'm finally getting to the
   point where I'm not seeing it anymore.

   Nigel: Now I really want to make sure it is on the at risk list
   for TTML2 because I really
   ... don't want to support it.

   Pierre: Based on my experience in imsc.js the feature really
   breaks the way TTML was
   ... designed. Unless someone stands up to say they really want
   it I don't think we should do it.

   Nigel: It is not on the at risk list for TTML2 CR2.

   Pierre: TTPE doesn't support it in TTML1, I'm not sure if it
   supports it in TTML2.

   Nigel: Does anyone want to take the action to raise an issue to
   add the
   ... `#region-implied-animation ` to the at risk list for TTML2?

   Pierre: I think it's reasonable to add it.

   Nigel: If we can close this meeting early then I'll go ahead
   and do that.
   ... Going back to the issue you want to only allow position on
   region? Is that only on text profile?

   Pierre: The same restrictions on tts:origin should be placed on
   tts:position, whatever those are.

   Nigel: Don't you want position on image?

   Pierre: You put it on the region that the image is in.

   Nigel: And you only allow one image per region?

   Pierre: Correct, just like in IMSC1.

   RESOLUTION: We will not support `#region-implied-animation ` in
   IMSC 1.1.

   Nigel: We also have another resolution to do what the issue
   requests.

   RESOLUTION: Apply the same constraints that exist on
   `tts:origin` to `tts:position`.

   github-bot, end topic

CSS actions review

   action-512?

   <trackbot> action-512 -- Pierre-Anthony Lemieux to Raise an
   issue with css wg requesting support for lineshear -- due
   2018-06-21 -- OPEN

   <trackbot>
   [16]https://www.w3.org/AudioVideo/TT/tracker/actions/512

     [16] https://www.w3.org/AudioVideo/TT/tracker/actions/512

   Nigel: The due date is today!

   Pierre: Realistically I will not get to this for another two
   weeks or so.

   Nigel: I've updated the due date to 5th July.

Meeting close

   Nigel: We've completed our agenda for today, thank you
   everyone. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

    1. [17]We will not support `#region-implied-animation ` in
       IMSC 1.1.
    2. [18]Apply the same constraints that exist on `tts:origin`
       to `tts:position`.

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [19]scribe.perl version
    1.152 ([20]CVS log)
    $Date: 2018/06/21 15:40:51 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 21 June 2018 15:42:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 21 June 2018 15:42:20 UTC