{minutes} TTWG Meeting 2017-03-16

Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/03/16-tt-minutes.html

We discussed publication of a WD for WR of IMSC and made the following resolution:


RESOLUTION: After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.

The review period under our Decision Policy for this resolution ends on 2017-03-30.

Parish notices:
Please let me know of any preferred focus topics for TTML2 by Tuesday next week.
Note that our meetings ongoing during April will be scheduled for 2 hours.
If you would like to step in and chair the April 6 meeting please let me know.

Minutes in text format:


   [1]W3C

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

                Timed Text Working Group Teleconference

16 Mar 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/03/16-tt-irc

Attendees

   Present
          Dae, Glenn, Nigel, Pierre, Thierry, Rohit, Mike

   Regrets
          none

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This Meeting
         2. [5]April meetings
         3. [6]IMSC
         4. [7]TTML
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This Meeting

   Nigel: For today, we will discuss WR publication of the IMSC
   update.
   ... Then we have TTML issues, with some "focus" issues that
   have already had some
   ... discussion on the reflector.
   ... I'd like to do some meeting planning too, in terms of
   duration and start times, and also
   ... focus topics for upcoming TTML discussions.
   ... Is there any other business for today? Or any particular
   points to cover that may not be on the agenda?

   group: [tumbleweed]

April meetings

   Nigel: I'm on vacation for the 6th April, happy for the meeting
   to proceed if someone
   ... wants to volunteer to chair, scribe etc.
   ... I would like to propose we plan for 2 hour meetings on the
   remaining April dates
   ... given our likely progress. Any views?

   Dae: I agree.

   Nigel: In that case I will default to 10am Boston start time, 2
   hour meetings in April.
   ... For future TTML focus topics I will return to that in the
   TTML agenda item.

IMSC

   Nigel: First, thank you Pierre for providing an updated version
   of the WD for WR for our review.

   [10]https://rawgit.com/w3c/imsc/WR-imsc-1.0.1/imsc1/spec/ttml-w
   w-profiles.html

     [10] https://rawgit.com/w3c/imsc/WR-imsc-1.0.1/imsc1/spec/ttml-ww-profiles.html

   Nigel: I raised an issue about security and privacy that we
   don't need to do now but should do soon.

   [11]https://github.com/w3c/imsc/issues/219

     [11] https://github.com/w3c/imsc/issues/219

   Nigel: There were two requests from Glenn, firstly to change
   "minor revision" to "revision",
   ... secondly to make a note about the possible change of
   name/version in the future.
   ... There was also some discussion about adding a reference to
   a change list in some form.
   ... At the moment the Scope summarises the changes but what is
   needed is a little more detail.
   ... One option that other groups use is to link to an HTML
   diff.
   ... Specifically I believe the change list is between this WD
   and the IMSC 1 Rec, not between
   ... this WD and the previous WD.

   Thierry: The goal for mentioning those changes is to focus the
   wide review on the new
   ... features only, so therefore you should have the differences
   between the WR WD and the previous Rec.

   Nigel: Firstly then, any problems with removing the word
   "minor"?

   group: No problems.

   Pierre: That's straightforward to do, I can do that easily.

   Nigel: We've had some discussion about the addition of warning
   text about a possible version change on the reflector,
   ... my personal view is it is not needed - there are a number
   of bad things folk might do but
   ... I don't think any warning we put there will prevent them
   from doing those things.
   ... Having said that I wouldn't have a strong objection to it.
   ... Any other views?

   Pierre: The likelihood that we will make the change is low so
   the addition is unwarranted.

   Glenn: I view this as similar to marking features as risk. My
   position is we should add the note.

   Mike: I think this matters to those on the phone call, and
   others including those in W3C probably do not care.
   ... I would lean towards leaving this alone and not adding the
   note, and hope we do not need
   ... to discuss it again.

   Nigel: Glenn will you object to a proposal to publish this WD
   for WR without the additional
   ... warning text?

   Glenn: No, as long as we have minuted this and the decision.

   Nigel: In that case I will (as Chair) call this in favour of
   publishing with minimal changes, i.e.
   ... without the warning message, in the cause of expediency.
   ... The third issue is about referencing a change set.

   Pierre: The idea of providing the reader with an unambiguous
   diff is really important.
   ... Viewers can do that themselves with the W3C diff tool.

   <pal>
   [12]http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.o
   rg%2FTR%2Fttml-imsc1%2F&doc2=https%3A%2F%2Fwww.w3.org%2FTR%2Ftt
   ml-imsc1.0.1%2F

     [12] http://services.w3.org/htmldiff?doc1=https://www.w3.org/TR/ttml-imsc1/&doc2=https://www.w3.org/TR/ttml-imsc1.0.1/

   Pierre: We could list the substantive changes, which would
   exclude the editorial changes.

   Thierry: For simplicity I would recommend using the diff tool.
   This can be done with a link
   ... in the spec, or I can save the results in a file that we
   can then link to.
   ... Let's make it simple, put a link to a file in the same
   directory, and I will generate the
   ... diff file and upload it to the publishing directory.

   Pierre: Okay then I will not create a link to the W3C HTML diff
   service, instead I will assume
   ... there will be a diff file included alongside and that will
   be a diff against the Rec.
   ... And separately we have to create a list of substantive
   changes?

   Thierry: No, you don't need to do that until we transition to
   CR.
   ... This is just to focus the wide review on the changes only.

   Pierre: §6.3.2 of the Process talks about substantive changes
   since the previous WD.

   Nigel: We made a change to the way the Active Area is
   calculated.

   Pierre: So I have to create that file, which will be
   straightforward.

   Thierry: Then just list it in the appendix.

   Pierre: I will do that.

   Nigel: Ok that sounds like a plan, the 4th and final thing is
   the Security and Privacy section.
   ... My question is: do we need this now, or can we add this at,
   say, CR?

   Thierry: It would be better to have it now, because we can ask
   the Security guys to review
   ... that during Horizontal Review. It could save us some
   problems.

   Nigel: Actually we must ask for that review, and they will ask
   us to fill in a form, and that
   ... will ask us if there is a section present, and we will say
   no, and they will say to create it then.
   ... Thinking practically, what do we need to put into the
   section? Just the points that
   ... I made in issue 219? Are there any other points?

   group: [No other comments]

   Nigel: In that case I don't mind drafting a pull request for
   this to allow us to review and
   ... include, and move a bit faster overall. I wouldn't mind
   Pierre doing to either (or anyone else).

   Pierre: [concerns about adding an extra 2 week review delay
   before publishing WR]

   Thierry: We could publish without it, and then add it in 2
   weeks and update the WR.
   ... I don't expect any feedback on this other than from the
   security people.
   ... That would allow us to save a bit of time.

   Pierre: I'm happy with that.

   Nigel: Ok that works for me, to go ahead without that section,
   rapidly work on that section,
   ... and then publish when we have agreed an update.
   ... If people are willing to give positive comments on the pull
   request sooner we could get it
   ... in by positive consensus.
   ... I could draft something by end of play today for review and
   hopefully completion by end of play tomorrow.

   Thierry: Would that be okay for everyone? Then we could include
   it next week.
   ... I would rather people would positively agree before, but if
   an issue is spotted then we
   ... could then make a subsequent update to the WR.

   Nigel: OK let's try that and see if we can make it work.
   ... Those are all the points to discuss, now I'd to move to a
   proposal to publish.
   ... This would be a "mutatis mutandis" proposal.

   PROPOSAL: After applying the changes agreed in principle in
   this meeting we will publish this draft of IMSC as a WD for WR.

   Nigel: If we publish this next week when will be the closing
   date for the review period?
   ... Sunday 7th May would be a little over 6 weeks.

   Pierre: There will be external organisations who may review,
   and some of those groups do
   ... not meet regularly, so we need to give them the opportunity
   to reach consensus.
   ... I'll use Sunday 7th May.

   RESOLUTION: After applying the changes agreed in principle in
   this meeting we will publish this draft of IMSC as a WD for WR.

   Nigel: Thanks, that's all on IMSC, let's take 3 minutes and
   come back and spend the next hour on TTML.

   Thierry: I have to leave now.

TTML

   Nigel: I'd like to go through the focus topics, agree next
   week's focus topics, then go through any other
   ... issues anyone wants to discuss. Will that work for
   everyone?

   group: [assent by silence]

   Nigel: First one is Inline Space

   [13]https://github.com/w3c/ttml2/issues/53

     [13] https://github.com/w3c/ttml2/issues/53

   Nigel: Are we at a point where we can agree that if the use
   case is micro-positioning of
   ... glyphs then that data is in fonts and we do not need to
   support negative inline space?

   Pierre: My data point is that this has proven useful in digital
   cinema over many years.
   ... If we are planning to filter feature support based on
   Lambda Cap then that would make
   ... things a lot simpler.

   Glenn: Even though there may be a problem to solve we do not
   need to solve it in the same
   ... way. The same problem as fillLineGap exists here in that
   micropositioning can only be
   ... achieved if there is knowledge of the font used at
   rendering time. We cannot require a
   ... sufficiently closed environment where that is known. So my
   position would be not to add this,
   ... especially since other solutions exist such as use of
   images.

   Nigel: Can we make a group disposition here that we will not
   support negative inline
   ... space for the purpose of glyph micro-positioning since
   other mechanisms exist?
   ... I am thinking ahead to the response to the original
   requester.

   Pierre: I will not oppose that.

   Nigel: Ok that sounds like a decision as I described. I will
   add a note to the issue.
   ... I have taken off the "Editor considers closed" label and
   closed the issue.
   ... The next issue is #239 3D and images

   [14]https://github.com/w3c/ttml2/issues/239

     [14] https://github.com/w3c/ttml2/issues/239

   Nigel: We discussed this a little last week but did not close
   it off because we wanted to make
   ... sure all the right people were involved in the decision.

   Mike: I withdrew my suggestion, as was clear in the issue. I do
   not think this is needed.

   Nigel: The only open question is if we want named left and
   right parameters for use in
   ... the @condition mechanism.

   Pierre: Why? What use case would this address?

   Glenn: The named parameters would allow for standardised
   approaches. There is no demanding
   ... requirement for this to be in TTML2. It could be added in
   the future. In the meantime
   ... people could add extensions if they want them. There's no
   provision in media queries
   ... for stereoscopic display targeting anyway.

   Nigel: Let's draw the axe down on this and do nothing, and
   close the issue. There's no
   ... requirement for it and we have plenty of other work to do.
   ... I will add a note to the issue and close it.
   ... Done
   ... Next issue is 96: Specify date as well as hours, minutes
   and seconds in time expressions

   [15]https://github.com/w3c/ttml2/issues/96

     [15] https://github.com/w3c/ttml2/issues/96

   Nigel: The summary of this is that there is a problem but we
   have no spec text to address it yet.
   ... I don't know exactly what the solution should be or if we
   should leave it for the future.
   ... One idea would be to permit ISO8601 format datetime values,
   for example.

   Glenn: My take on this was that we would leave it for the
   future. ISO8601 processing is
   ... a little complex and can require knowledge of external
   information.
   ... This would certainly have a testing impact. I did not want
   to suggest a syntax.
   ... I don't mind if someone else wants to draft something.

   Nigel: I don't think there's an answer for this in SMIL.
   ... Is the reason nobody else has a comment on this that they
   do not use clock times?

   Pierre: Yes, that's my reason.

   Glenn: SMIL does actually offer an ISO8601 based syntax as an
   alternative for begin, end and dur I guess...

   <glenn>
   [16]https://www.w3.org/TR/smil/smil-timing.html#Timing-Wallcloc
   kSyncValueSyntax

     [16] https://www.w3.org/TR/smil/smil-timing.html#Timing-WallclockSyncValueSyntax

   Nigel: Thanks, that would make sense as a solution in TTML when
   ttp:timeBase="clock"
   ... I don't think it would make sense in other timebases nor
   would it support a "days"
   ... component in general time expressions.
   ... I don't mind taking the action to propose that syntax.

   Glenn: If the proposal is to adopt the SMIL syntax then I don't
   mind taking it from there.
   ... What's the attitude of the group - do we want it or not? I
   am ambivalent towards this.

   Nigel: The group also seems to be ambivalent but there is a
   strong use case in live
   ... scenarios, either for capture of text or for live
   authoring.

   Glenn: I think the phrase here is "without objection"

   Pierre: Why not use UTC?

   Nigel: UTC doesn't offer a date either, and in fact the hours
   component is locked off so cannot
   ... be used to express date when ttp:timeBase="clock".

   Pierre: Alright.

   Nigel: I've added a comment, and will change the labels.

   Glenn: Just to mention that syntactically this makes it easy to
   integrate because the whole
   ... clock value including date is wrapped in a "wallclock()"
   wrapper. It is syntactically easy
   ... to integrate in the current syntax.

   Nigel: Thank you!
   ... The next issue is 160 use of offset-time expression in
   smpte mode

   [17]https://github.com/w3c/ttml2/issues/160

     [17] https://github.com/w3c/ttml2/issues/160

   Nigel: I think the problem here is that there is no
   quantisation rule in case a time expression
   ... does not evaluate to a frame value.

   Pierre: Shouldn't we simply restrict the permitted time
   expressions so they do not have
   ... this problem?

   Glenn: We have deprecated this in part in TTML2 but this is a
   corner case.

   Pierre: Can we not say that it was unspecified before, it is
   deprecated now, and we are
   ... leaving it unspecified.

   Glenn: That would be fine with me.

   Nigel: Where is the deprecation?

   Glenn: It is at §12.3.1 at the end of that section.

   [18]https://w3c.github.io/ttml2/spec/ttml2.html#timing-time-val
   ue-expressions

     [18] https://w3c.github.io/ttml2/spec/ttml2.html#timing-time-value-expressions

   Nigel: I see. Are there any exceptions where even with the
   deprecation invalid timecode
   ... frame values could arise? Looks like the answer is no from
   the equations in I.3.

   Glenn: As far as I am aware the deprecation covers all of the
   cases.

   Nigel: Ok is everyone happy to do nothing on this?

   Group: [no objections]

   Nigel: Great, I will add a note to the issue and close it.
   ... Done!
   ... Thanks, those were all the focus topics for this week.
   ... Looking at next week, what would people like to focus on?

   Pierre: [19]https://github.com/w3c/ttml2/issues/240
   emphasis-position vs CSS text-emphasis-position + Mongolian
   ... It sounds like we are nearly ready to get to an agreement
   on this.

     [19] https://github.com/w3c/ttml2/issues/240

   Nigel: That's on the list.

   Pierre: Related to that is issue #254.
   ... We should be able to close both together.

   Nigel: Okay I'll add that to the list and let r12a know we plan
   to discuss this on next week's call.

   Dae: Can we talk about the IMSC mapping/fallback/transform
   issue?

   Nigel: Yes, thank you for putting that draft together in the
   week as you promised, we will
   ... have that on the agenda for next week.
   ... Ok we need more for the list than that - if anyone has any
   other suggestions over the
   ... next few days please email me.
   ... In the meantime, we had no AOB, so I will close the
   meeting. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

    1. [20]After applying the changes agreed in principle in this
       meeting we will publish this draft of IMSC as a WD for WR.

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [21]scribe.perl version
    1.152 ([22]CVS log)
    $Date: 2017/03/16 16:24:49 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [22] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 16 March 2017 16:30:17 UTC