{Minutes} TTWG meeting 2019-10-03

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


Please note that we agreed to adjust the meeting time to track the US DST change, so the UTC meeting time will be changed by +1 hour to 1600, for 1 hour meetings; the first meeting this will affect will be on 2019-11-07. If this will cause you any difficulties please let me know.

Those minutes in text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

03 October 2019

   [2]Agenda. [3]IRC log.

      [2] https://github.com/w3c/ttwg/issues/70

      [3] https://www.w3.org/2019/10/03-tt-irc


Attendees

   Present
          Atsushi, Cyril, Gary, Glenn, Nigel, Pierre, Thierry,
          tmichel

   Regrets
          Andreas

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [4]Meeting minutes
         1. [5]This meeting
         2. [6]Remove constraint on presence of xml:id (#989).
            ttml2#1162
         3. [7]Add informative note to tts:fontStyle recommending
            use of tts:shear instead of tts:fontStyle="italic" for
            Japanese text. ttml2#1120
         4. [8]Fix syntax coloring problem by using character ref
            for apostrophe. ttml2#1170
         5. [9]Add support for #font imsc#485
         6. [10]AOB - DST
         7. [11]Charter update
         8. [12]Meeting close
     * [13]Summary of resolutions

Meeting minutes

   Log: [14]https://www.w3.org/2019/10/03-tt-irc


     [14] https://www.w3.org/2019/10/03-tt-irc


   <glenn> irc only

This meeting

   Nigel: Anything for WebVTT?

   Gary: No, nothing to discuss

   Nigel: Then we have 2 TTML2 issues, and maybe we can quickly
   resolve the editorial issue about apostrophes too.
   … Plus one IMSC issue.
   … In AOB I've included the Charter, but more pressingly the
   upcoming DST change.
   … Is there any other business to cover?

   Pierre: [wants to cover the font issue already on the agenda
   for IMSC]

Remove constraint on presence of xml:id (#989). ttml2#1162

   github: [15]https://github.com/w3c/ttml2/pull/1162


     [15] https://github.com/w3c/ttml2/pull/1162


   Nigel: [summarises issue]

   Pierre: My understanding is the proposal is to revert to the
   constraints of TTML1
   … which as was pointed out by many leads to some unexpected
   outcomes in some corner cases.

   <glenn> We have an approval on this already, so given there was
   no inclination to accept my suggestion to go further, we can go
   with what we have now.

   Nigel: This PR removes any sense of definition that an out of
   line [thing] must have an xml:id and a [thing] without
   … an xml:id is not an "out of line" [thing].
   … That brings it into line with TTML1.

   Pierre: Right, I think this is good to go.

   Nigel: Any other views or questions?

   Cyril: So we're favouring consistency with TTML1 even though we
   know there is a weird behaviour.
   … Glenn suggested an option to edit TTML1. Is that an option?

   Pierre: Unless there's a concrete use case I think we should
   not bother.
   … There's more risk and effort backporting something to TTML1
   than leaving it as is.

   Nigel: I agree I haven't seen a concrete use case.

   Pierre: There's a bunch of unexpected behaviours but every time
   we've run into one we've decided that
   … if there's no use case we should accept it, and we should
   continue doing that.

   Cyril: I don't know if it is a concrete use case but clearly
   [scribe missed due to audio break-up]
   … we should at least have tests and check that it is
   consistent.

   Pierre: I really like that idea, it's like what we did with
   some timing corner cases.

   Nigel: Glenn already mentioned on the issue that he could
   create validation and presentation tests.

   Nigel: I think we have consensus to go ahead with this if there
   are no other points?

   <glenn> I need to add tests for this PR before merging anyway,
   so I can add something for bare and alone unidentified region

   Cyril: Yes
   … A lone unidentified region means nothing will ever be
   displayed.

   Pierre: That's right, we should create a test like this, it's
   an excellent idea.

   PROPOSAL: Proceed with this PR as is and add associated tests.

   Nigel: Any objections?

   Resolved: Proceed with this PR as is and add associated tests.

Add informative note to tts:fontStyle recommending use of tts:shear
instead of tts:fontStyle="italic" for Japanese text. ttml2#1120

   github: [16]https://github.com/w3c/ttml2/issues/1120


     [16] https://github.com/w3c/ttml2/issues/1120


   Nigel: The question here is do we have consensus to move this
   issue to IMSC?

   Cyril: Yes from me, at least.

   PROPOSAL: Move this issue to IMSC

   Nigel: Any objections?

   Resolved: Move this issue to IMSC

   Pierre: I can do this now, to IMSC repo?

   Nigel: Yes

   Pierre: Done!

Fix syntax coloring problem by using character ref for apostrophe.
ttml2#1170

   github: [17]https://github.com/w3c/ttml2/pull/1170


     [17] https://github.com/w3c/ttml2/pull/1170


   Nigel: Seeking a view from TTML editors?

   Pierre: It's a pain to do this. There are 250 changes.

   Cyril: It's difficult, I agree with Nigel that it will not be
   easy for other Editors to remember it and they might forget to
   do it.
   … But I also think that Glenn is doing all the editing these
   days and we heavily rely on him so if it hinders him
   … from doing his job we should accept the change. What he said
   is also correct that future editors can revert the change.

   <glenn> Without this change, I cannot do any further edits.

   Cyril: On the editorial side I would approve the request.
   … The burden will be on Glenn to maintain it if other Editors
   contribute and use ' instead of &apos;

   <glenn> And it is a trivial change using M-x query replace.

   PROPOSAL: Accept this pull request

   <glenn> Sure, that's reasonable.

   Nigel: Any objections?

   Pierre: I don't object to this change but the characterisation
   on the pull request is wrong - it is not trivial.

   Resolved: Accept this pull request

   Nigel: I will press the Approve button.

   <glenn> Thanks

   Nigel: Done

Add support for #font imsc#485

   github: [18]https://github.com/w3c/imsc/pull/485


     [18] https://github.com/w3c/imsc/pull/485


   Nigel: I saw a potential for differing interpretations here,
   and proposed some options.

   Pierre: I think we should go with bytes transferred.

   Nigel: That's fine, but given the "loaded" terminology from
   WOFF, maybe we should use a different non-conflicting term.
   … WOFF says "loaded" is post-decompression.

   Pierre: [Wonders what the HTTP spec calls this]

   Cyril: What happens if HTTP does gzip compression? Do we count
   it before de-compression or after?

   <glenn> <data/> has a well defined @size attr that applies when
   one has <font><source><data/></source></font>

   [19]RFC2616 transfer-length

     [19] https://tools.ietf.org/html/rfc2616#section-4.4


   Pierre: The link above defines transfer length
   … the wording specifies the post-gzip decompression size.
   … Let's look at the size attribute in data in TTML2

   Nigel: It has length not size, I think we mean that.

   <glenn> yes, @length that is

   Pierre: It talks about the number of decoded bytes

   Nigel: Presumably that must be post-decompression for it to
   make any sense

   Pierre: I think we should keep it simple and use
   transfer-length.

   <glenn> actually, @length is only used with simple data
   embedding; so it would not apply to sourced embeddings;
   however, the model may be useful

   Pierre: This is after any transfer coding, i.e. after gzip.
   … What about entity length?
   … This is section 7.2, before any transfer-codings have been
   applied.

   Nigel: What is a transfer-coding?

   Pierre: like gzip

   <glenn> I would prefer that length mean post-transfer-encoding
   processing, i.e., entity length

   Cyril: Side question: do we have any tools for verifying
   against the HRM?

   Pierre: I'm not aware of an open source tool that does it, but
   I have not checked TTV recently.

   <glenn> by which I really mean post-decoding of any
   transfer-encoding

   Cyril: We could be looking for a solution that will never be
   used.

   Pierre: Even though it is not formally implemented, the goal is
   to prevent somebody from doing something stupid
   … like providing a 100MB or 1GB font resource and wondering why
   the client fails.
   … It's setting reasonable limits.

   Cyril: We don't need the HRM for that though?

   Pierre: No but it's the right place in the spec for it, to
   Glenn's point.
   … Here I think we're just looking for the right term.
   … In the case of HTTP it is called the entity-length.

   Cyril: You could say that if you download everything locally
   then it should be that.

   Pierre: Nigel was pointing out that "loaded" has a definition
   in WOFF.

   <glenn> if "entity length" means the number of bytes in a
   resource after removing any transfer encoding, then that is
   what I would suggest be used

   Cyril: I would say we note that we don't mean the WOFF term.

   Nigel: I still think that would be vague.

   <glenn> we should not tie this constraint to the semantics of
   internal compression support in a given font format

   Nigel: I think we're in the right territory with entity-length
   and transfer-length and just need to work out which one we
   want.

   Pierre: Is there anything else blocking this PR?

   Nigel: Nothing else as far as I can tell.

   Pierre: I'm going to try to come up with some text right now.

   Nigel: Looks like transfer-length could be zipped, whereas the
   entity-length is pre-transfer-coding, and therefore,
   … assuming that the post-transfer-decoding generates the same
   bytes as the pre-transfer-coding, then entity-length
   … is what we want.

   Pierre: [working on an update that might be ready in a few
   seconds]

   <glenn> notes that constraints on image length is based on
   Decoded Image Buffer size, which suggest something like entity
   length

   Pierre: [pushes the change]

   Nigel: [reviews change]

   -> [20]https://github.com/w3c/imsc/pull/485/files/
   29b0f4de1917a1bf01c36defc7542f9f4f99282d..108a4dfaff9bc0fb98c97
   2bb9b773b2032d7000d

     [20] https://github.com/w3c/imsc/pull/485/files/29b0f4de1917a1bf01c36defc7542f9f4f99282d..108a4dfaff9bc0fb98c972bb9b773b2032d7000d


   Pierre: I think that addresses the issue you raised Nigel.

   Nigel: Yes

   Pierre: I plan to defer other issues.

   <glenn> just approved

   Nigel: Just looking at the timeline of this PR, the key date
   was 14 days ago when the change was submitted to
   … address the TPAC meeting resolution.

   Pierre: Yes

   Nigel: Does anyone need time to review this latest change
   before we merge it?

   Cyril: Can I have until the end of the day?

   Pierre: Absolutely.
   … Assuming there's no major substantive change I'll work on an
   FPWD package, which may need some editorial changes,
   … to address publication checker issues, in which case I'll
   open another pull request and request quick review.

   Nigel: That seems reasonable.

   Pierre: All the other issues filed I will schedule for next WD
   and start working on them.

   SUMMARY: Change accepted by those in the meeting, PR can be
   merged no earlier than end of current working day.

   <glenn> btw, I posted some recent issues against IMSC 1.2,
   which may require substantive changes

   Cyril: Did Vladimir review this pull request?

   Nigel: I don't think so.

   Cyril: We should at least ping him.

   Pierre: For the feature in general or the specific change?

   Cyril: He may have a valuable comment, but we shouldn't delay
   FPWD.

   Pierre: I agree, how do we do it. I can send him an email?

   Cyril: Yes go ahead. I'll talk to him about it next week too.

AOB - DST

   Nigel: I proposed 2 options on the agenda.
   … [summarises agenda proposals]
   … We can't have it so everyone wins here.

   Cyril: If it goes 1 hour earlier, then until mid-December I
   would not be able to attend.

   Pierre: I've moved my schedule around so joining an hour
   earlier might be very difficult for me.

   Atsushi: I can manage 1 hour later in JST.

   Nigel: Thank you, in that case I think we will adopt proposal
   1, to keep the same local time and make UTC track the DST
   change in the US.
   … I'll send that out and if any non-attendees here have a
   comment to make then they can do so on the reflector.

Charter update

   Atsushi: No further update from me.

Meeting close

   Nigel: We've completed our agenda, thank you everyone.
   … Please do add agenda topics to next week's agenda issue on
   the ttwg repo.
   … [adjourns meeting]

Summary of resolutions

    1. [21]Proceed with this PR as is and add associated tests.
    2. [22]Move this issue to IMSC
    3. [23]Accept this pull request


    Minutes manually created (not a transcript), formatted by
    Bert Bos's [24]scribe.perl version Mon Apr 15 13:11:59 2019
    UTC, a reimplementation of David Booth's [25]scribe.perl. See
    [26]history.

     [24] https://w3c.github.io/scribe2/scribedoc.html

     [25] https://dev.w3.org/2002/scribe/scribedoc.htm

     [26] https://github.com/w3c/scribe2/commits/master/scribe.perl