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

{minutes} TTWG Meeting 2018-02-15

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 15 Feb 2018 17:46:21 +0000
To: TTWG <public-tt@w3.org>
Message-ID: <D6AB76A2.55216%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/02/15-tt-minutes.html

For TTML2 CR the following timeline will apply:

1. Final edits and pull request approvals/merges over the next night/day.
2. I will issue a call for consensus to transition to CR tomorrow. Our Decision Policy as defined in our Charter will begin at that point and if there are no objections over the following 10 working days the decision will be final.

Please note that we resolved to permit early merging of some pull requests on the basis that objections can be filed during that call for consensus period.

In text format:


   [1]W3C

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

                Timed Text Working Group Teleconference

15 Feb 2018

   See also: [2]IRC log

      [2] https://www.w3.org/2018/02/15-tt-irc

Attendees

   Present
          Nigel, Glenn, Pierre, Cyril, Thierry

   Regrets
          Andreas

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [3]Topics
         1. [4]This meeting
         2. [5]IMSC 1.0.1
         3. [6]TTML2 Pull Requests
         4. [7]Handling non-kana text for rubyAlign with
            spaceAround or spaceBetween ttml2#251
         5. [8]TTML2 Pull Requests.
         6. [9]Meeting close
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This meeting

   Nigel: Today we need to note the request to transition IMSC
   1.0.1 to PR, but the main
   ... business to cover is TTML2, and getting to a CR document we
   can request transition for.
   ... We need to close off all the issues and pull requests with
   respect to CR1, either by
   ... deferring, or agreeing any quick technical points, or
   merging the related pull request
   ... if possible. Then at the end of the meeting hopefully we
   have a version that we can
   ... resolve to transition to CR.
   ... If a long technical conversation is needed, we will need to
   defer the issue to after
   ... CR1 - otherwise we won't get through this.
   ... Does that work for everyone?

   Glenn: Always happy to be aggressive.

   Nigel: Any other business or specific points to raise that may
   not already be obvious?

   group: No other business

IMSC 1.0.1

   Thierry: The transition request to PR was sent yesterday; it is
   now in the hands of the Director.
   ... I think there's unlikely to be a meeting so we should
   expect a response by Tuesday I hope.
   ... I still need to finalise the questionnaire for AC review
   which I will do later today. Once I
   ... get the OK from the Director I will request publication.
   The document is in place,
   ... validated and ready.
   ... Publication is really to announce on the W3C home page and
   change the latest link (by the webmaster).

   Nigel: Fantastic, thank you Thierry, and Pierre for preparing
   the version.

   Thierry: PR lasts 28 days so we should be ready to move to Rec
   at the end of March probably,
   ... or early April.

TTML2 Pull Requests

   Nigel: Let's iterate through the TTML2 pull requests please. I
   see 24 open, some have a
   ... "agenda" label.

   Cyril: I suggest the i18n first, though things have changed
   overnight with r12a approving
   ... many of them - I'm in the process of merging the approved
   ones 14 days or older.

   Glenn: I finally last night began to review the i18n issues I
   hadn't done before. I already
   ... made one minor change, some of the others need some minor
   changes.

   Cyril: #605 is approved and 17 days old - I plan to merge as
   soon as the merge from master travis build is complete.

   group: [ok]

   Cyril: #613 is next.

   Nigel: That's the pinyin example.

   Pierre: This has 2x approve, 0x dissent, can we merge it?

   Glenn: Can you make a minor editorial change Cyril? You started
   a sentence with a coded
   ... name of an attribute, which is avoided in all TTML2.

   Cyril: Ok, I'll change it to "The tts:ruby attribute". That's
   editorial.
   ... [makes the change]

   Nigel: OK, we're good to merge #613.

   Glenn: I'll approve it.
   ... For the record the word "Jay" is not pinyin, it's an
   English translation.

   Cyril: #617 is next.
   ... r12a has approved it.

   Glenn: I have an issue here - you removed a paragraph that says
   what to do if a computed
   ... value is not supported. That needs to be restored because
   the sentence about what to
   ... do if not supporting is orthogonal. On one case we are
   talking about a specific value being
   ... not supported, in the other if no value is supported.

   Cyril: OK, I was under the impression that there's no such
   thing as not supported because
   ... you can always do fallback.

   Glenn: It's formulaic - if absent here it's an inconsistency.

   Cyril: I don't think this part was of concern to r12a.

   Glenn: It does not invalidate the part he agreed.

   Cyril: [fixes it]

   Glenn: I'll approve that.

   Nigel: Okay, that's good to merge then.

   Cyril: Next is #618. It's approved by r12a only and is 15 days
   old.

   Glenn: I think that looks okay.
   ... Changing complex to double-sided, and the example, yes,
   that's okay, I'll approve.

   Nigel: Okay, that's good to merge then.

   Cyril: Next is #619
   ... Again approved by r12a only.
   ... and 15 days old.

   Glenn: [reviews] I'll approve this.

   Nigel: Great, that can be merged.

   Cyril: #623 is the next one, approved by 2, 14 days old.
   ... This is the one about mismatch.

   Nigel: Unless there's a significant issue we should go ahead
   and merged, we've discussed this at length already.

   Glenn: There's inconsistency in Ruby/ruby case. I'll approve.

   Nigel: We can merge that now.

   Cyril: The next is #625
   ... This has one request change, no approvals and is 13 days
   old.
   ... It is related to issue #281 and #251. It is about the
   definition of glyph area.
   ... I asked r12a if he would be happy if we were to define
   glyph area based on the CSS3 "typographic character unit"
   ... but that is in WD only.

   Glenn: I could not accept that because it has not been accepted
   in the industry, and is
   ... semantically confusing because it confuses character and
   glyph.

   Cyril: Can we define glyph area based on grapheme cluster then?

   Glenn: No, grapheme cluster is a linguistic unit, glyph areas
   are about presentation.

   Cyril: They're a unit of the writing system.

   Glenn: That's linguistic.

   Cyril: I disagree with that.

   Glenn: I suggest we adopt Nigel's proposal 9 days ago to leave
   it as is.

   Nigel: I also made a point about whether text orientation
   applies to glyphs or glyph areas.

   Glenn: We're in the semantic mud here because a glyph area is a
   construct that includes
   ... referring to a specific glyph index, referring to a
   specific shape in the font, so ...
   ... yes, it wouldn't hurt to make that change.
   ... I would not be prepared to introduce grapheme cluster or
   typographic character unit.

   Cyril: We already refer to grapheme cluster once.

   Glenn: I see, I copied and pasted the existing use of grapheme
   cluster out of a CSS document.
   ... I will raise an issue to editorially resolve that in CR.
   ... I think our response on #281 is that the group is not
   currently willing to introduce
   ... grapheme cluster as a term at this time.

   Cyril: The trouble is there is no good solution, because glyph
   area is not well defined.

   Pierre: The default is to stick with XSL-FO, however loosely it
   is defined.

   Cyril: Could we resolve to say we will fix the definition?

   Glenn: We define glyph area.

   Cyril: By reference to XSL 1.1.

   Nigel: By my reading that definition does not conflict with
   grapheme cluster or typographical character unit.
   ... They could coincidentally be the same thing.

   Glenn: The current definition is wide enough.

   Pierre: if it is neither the XSL nor the CSS definition it is
   not helping.

   Glenn: It is not inconsistent with either.

   Pierre: Why not just refer to XSL?

   Glenn: To make it clear, and to introduce the concept of a
   spacing glyph area or a non-spacing glyph area.

   Cyril: That's orthogonal.

   Pierre: Sounds like we're going to say it works for us as is.

   Glenn: Are you suggesting we don't change anything in #625?

   Cyril: Yes, approve the pull request as is.
   ... [makes small editorial tweak]

   Nigel: [adds note to #281]
   ... I've approved that.

   Cyril: Even if r12a does not approve this or review it I will
   still merge it?

   Nigel: Yes

   Cyril: Those are all the i18n pull requests. Can we check the
   status of issue #251?

Handling non-kana text for rubyAlign with spaceAround or spaceBetween
ttml2#251

   github: [12]https://github.com/w3c/ttml2/issues/251

     [12] https://github.com/w3c/ttml2/issues/251

   Glenn: This comes back to the definition of glyph area!
   ... @r12a asks which of the two is correct. I would say that
   the first one is preferred. I can
   ... see how he is asking if the sequence of three base latin
   characters j a y would be treated
   ... as a single glyph area. Ideally we would have a note or
   some language that says that for
   ... scripts other than... The real problem is that the
   rubyAlign language makes use of the
   ... glyph area counts, and if you don't know what a glyph area
   is I can see how that would
   ... lead to confusion. The natural interpretation for latin
   text is that each latin base character
   ... is a separate glyph area, arguing for the second treatment.
   From a user perspective you
   ... would want to see the first one.

   Cyril: According to the definition of glyph area today, how
   many do we have, 2 or 7?
   ... In #281 r12a was talking about Arabic words and asking
   essentially the same question.

   Glenn: Yes. I can see the question.

   Cyril: I get the sense that we need some technical change here,
   not just an editorial one.
   ... How do we deal with the comment? Are we prepared to let
   this out in CR1 and possibly
   ... improve it in CR2?

   Nigel: Are we saying that @r12a's second rendering is correct
   by the current definition and
   ... we are happy to leave it at that even though it may not be
   ideal?

   Pierre: Happy with that.

   Cyril: +1
   ... Can we respond saying we will prepare test vectors testing
   this and will deal with any
   ... implementation feedback based on those?

   Glenn: +1

   Pierre: +1

   RESOLUTION: We will create tests to verify this behaviour and
   will be open to implementation feedback based on the results of
   those tests during CR.

   github-bot, end topic

TTML2 Pull Requests.

   Nigel: Let's look at #594.

   Glenn: Nigel and I discussed this yesterday and he persuaded me
   that the proposal to add
   ... schemas is defining something that was not there before,
   allowing the author to specify
   ... an actual schema as opposed to some defaulting process. On
   that basis, even though I
   ... think there would be no risk in adding this, I understand
   that there are concerns and that
   ... it might not be fully fleshed out at this point. In
   particular, the logic for combining profiles
   ... does not answer the question of how to combine schema
   definitions. The bottom line
   ... is I'm prepared to remove the schema elements part of this
   PR in order to move forward.

   Cyril: You can open a new issue and mark it as ttml.next.

   Glenn: I will mark the pull request as ttml.next to remind me.

   Nigel: [adds a comment to the pull request]

   group: [discussion of process] agrees to merge modulo removal
   of schema and schemas, assuming that it can be approved in the
   next day.

   Nigel: Next one is #603

   Cyril: The simplest thing is to make the base text in TTML1 and
   TTML2 match.

   Glenn: Correct. I did not review the material that went into
   TTML1.

   Nigel: I think you were in that discussion.

   Pierre: We can correct both TTML1 and TTML2 post-CR
   simultaneously.

   Glenn: The no-op procedure is to do nothing here, and I'm happy
   to go ahead into CR
   ... with it open.

   Pierre: I would object to that.

   Glenn: I see a path to resolving this - what was there before
   was broken.
   ... I made some changes in the pull request, and there are a
   couple left, one to reintroduce
   ... the set element, and the other to handle some of the
   semantics from w3c/ttml1#193.
   ... I might be able to fit in exactly the same language as
   TTML1 3rd Ed, and can fix the portion
   ... allowing it to be before.

   Nigel: You can't resolve the timing without creating anonymous
   spans.

   Glenn: I plan to allow for anonymous span creation to be done
   prior to ISD construction and
   ... that it does not need to be done twice.

   Nigel: I need to review that text.

   Pierre: If it does not match TTML1 for better or worse (and I
   can't backport it to TTML1 Third Edition) then I plan to file
   an objection.
   ... I would like to take the time to fix both post CR rather
   than rushing today. The simplest
   ... is to merge what's in TTML1 today and then file an issue if
   there's a problem.

   Glenn: I think it can be fixed today.

   Nigel: The next one is #616. Open 15 days, some conversation,
   no approvals.
   ... Last week we covered this and Glenn said it was on his
   list, but there's been no approval so far.

   Glenn: There are a lot of changes here.

   Nigel: I moved the media timing section as requested.

   Glenn: I'm not prepared to agree with this today.

   Pierre: I'm neither happy nor unhappy with this, but given the
   duration it has been opened I can approve it.

   Nigel: The next one is #620. 1 approval, open 14 days, so I
   think this can be merged.

   Glenn: As it's a note I'm approving it.

   Nigel: Thanks. Next is #632, open 9 days ago, and 1 request for
   changes.

   Glenn: I've changed the name of #661.

   Nigel: It's only been 3 days since the most recent substantive
   changes.

   Pierre: By consensus on this call we can choose to merge this
   but note that people still have
   ... 2 weeks to object.

   Nigel: I can go ahead with that at this time, and note in the
   call for consensus those
   ... pull requests that were merged early.

   RESOLUTION: Allow an early merge of #632

   Nigel: The next is #638, 7 days old, 3x approvals.

   RESOLUTION: Allow an early merge of #638

   Nigel: Next: #639, open 6 days, 1 request for change, 1
   approval.
   ... I think this is currently not well formed.

   Glenn: I view this as a nit, can it be resolved after CR?

   Nigel: Can we please add a statement that conflicts are an
   error state?

   Glenn: I can do that in the next few hours.

   Nigel: That will allow me to approve it.
   ... We have to do CR exit criteria for CR. I opened #667
   earlier.

   Glenn: I have an issue with "independent" because it is not
   defined anywhere. I want a note
   ... that qualifies that by saying that the term "independent"
   is not defined.

   Nigel: We don't need that. The Director will decide what is
   independent.

   Pierre: I don't agree with a note, the best we can do is refer
   to the Process document.

   Thierry: "Independent" is not defined - a lot of documents go
   through the Process, some
   ... do not have implementations. It's a generic term. I think
   everyone understands what
   ... independent means - two implementations by the same company
   are not independent.
   ... As Nigel said, the Director will decide.

   Pierre: I don't think we should change our exit criteria here,
   compared to other TTML based specs.

   Nigel: The document is governed by the Process already, so we
   don't need to state more.

   Pierre: I object to adding a note.

   Cyril: I'm approving the pull request as is and object to
   removing "independent"

   Pierre: Likewise I approve it and object to removing
   "independent"

   Glenn: We need to cover feature designators.

   Nigel: In my view we can cover feature designators after CR
   because it is part of test suite
   ... development.

   Glenn: I'd be fine with that. A strict reading of substantive
   changes could be triggered
   ... because feature designators form part of profile documents,
   which are normative.

   Nigel: I think I'd agree that adding a feature designator would
   require a CR2.

   Glenn: How long does it add to the process?

   Pierre: A month. I think we have enough time for this.

   Nigel: +1
   ... I think we can take a bit more time over feature
   designators and issue a CR2 without
   ... any change to the end date for work on this spec.

   Glenn: I hope so, but I'm nervous. In that case we don't need
   to merge the feature
   ... designator pull request unless we want to.
   ... I've opened #664, which we could merge. I listed a few
   others in the issue that I
   ... can do today. There are 5 that are extensions to TTML1 that
   we haven't featurised yet.

   Nigel: I'd be happy to wait for those all to be in the pull
   request today.

   Glenn: I'll do those today and then we have tentative approval
   to merge?

   Nigel: yes

   Glenn: It'll be marked as merged early.

   <tmichel> diretor will consider adequate implementation
   experience

   <tmichel>
   [13]https://www.w3.org/2018/Process-20180201/#implementation-ex
   perience

     [13] https://www.w3.org/2018/Process-20180201/#implementation-experience

   Glenn: We need to list the at risk features too.

   Nigel: I think we cannot get confidence on a full list of at
   risk features so we should go
   ... with what we have today and if we need to change it do so
   in a CR2.

   Glenn: This is in issue #662.

   Pierre: I think we should go with what we have today also.

   Nigel: I think given the time we have to adjourn, and by
   default will defer the remaining
   ... open pull requests and their associated issues.

Meeting close

   Nigel: Thanks everyone for getting through so much today. I'll
   aim to issue a call for consensus for transition to CR
   tomorrow.
   ... [adjourns meeting]

Summary of Action Items

Summary of Resolutions

    1. [14]We will create tests to verify this behaviour and will
       be open to implementation feedback based on the results of
       those tests during CR.
    2. [15]Allow an early merge of #632
    3. [16]Allow an early merge of #638

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.152 ([18]CVS log)
    $Date: 2018/02/15 17:40:04 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 15 February 2018 17:46:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 February 2018 17:46:52 UTC