Re: {Minutes} TTWG Meeting 2020-11-19

The deadline for easy adoption of patent policy 2020 has been extended until 2020-12-04 so we now have our full decision review period available for yesterday's resolution to adopt, until 2020-12-03. As always, it is more helpful to lodge any queries or objections sooner rather than later, in case there may be a possibility of resolving them and continuing with the resolution.

Nigel


________________________________
From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Sent: 19 November 2020 5:30 PM
To: public-tt@w3.org <public-tt@w3.org>
Subject: {Minutes} TTWG Meeting 2020-11-19

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

We made 2 resolutions today:

  1.  add the Netflix profile to the TTML Profile Registry as requested using identifier nst1
  2.  adopt Patent Policy 2020

As per our Decision Policy the review period for these resolutions expires on 2020-12-03 however please note that there is a deadline of 2020-11-27 for adopting the Patent Policy using an "easy change" process where multiple Working Groups can simultaneously adopt it. I will investigate the options, but in the meantime strongly recommend that you enter any review comments by 2020-11-26 to allow for processing given different time zones. This would apply even if your comment is "I need longer to review and accept this." Please note that Atsushi linked to a useful summary of the changes as presented to the DID WG at https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47
[https://lh6.googleusercontent.com/6fkOm8FLd5nsVMTuEj40uZjKwguZEJJ-TCIp5aeuoDy8j0MZ_iqOpExCqEzwLPsOVtNccSma4Q=w1200-h630-p]<https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47>

DIDWG Virtual TPAC 2020 Sessions<https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47>
Decentralized Identifier WG FF2F Sessions - TPAC Edition Day 1: November 2, 2020 Chairs: Brent Zundel, Dan Burnett Location: Cyberspace 1
docs.google.com


Those minutes in text format:

   [1]W3C

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

                Timed Text Working Group Teleconference

19 November 2020

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2020/11/12-tt-minutes.html
      [3] https://github.com/w3c/ttwg/issues/159
      [4] https://www.w3.org/2020/11/19-tt-irc

Attendees

   Present
          Andreas, atsushi, Cyril, Gary, Glenn, Glenn_IRC_only,
          Mike, Nigel, Pierre

   Regrets
          Glenn_on_audio

   Chair
          -

   Scribe
          cyril, nigel

Contents

    1. [5]this meeting
    2. [6]remove applicability of direction on p
    3. [7]TTML Profile Registry
    4. [8]Patent Policy 2020
    5. [9]Default branch name
    6. [10]Meeting close
    7. [11]Summary of resolutions

Meeting minutes

  this meeting

   nigel: we have regrets from Glenn
   … the first topic is what his regrets apply to
   … but we can use the opportunity to get the discussion going

   pal: yes

   <atsushi> (will come shortly. still in previous)

   nigel: since sending the agenda on tuesday I modified the order
   to put the registry next
   … we just published
   … I still haven't got the MPEG liaison

   <glenn> I'm here, IRC only.

   cyril: I'll send you the liaison again

   nigel: not sure if we need more on Process 2020
   … the conclusion last time was that gary would send something
   around

   gkatsev: the patent 2020 there is a time limit if we want to do
   the quick adoption of that

   nigel: and the last topic is changing the default branch name
   … from master to main

   nigel: any other business for the agenda

   nigel: seems not

  remove applicability of direction on p

   github: [12]https://github.com/w3c/ttml2/pull/1214

     [12] https://github.com/w3c/ttml2/pull/1214

   nigel: we have comments from Glenn
   … Pierre tried to address Andreas' comments
   … Andreas approved them
   … Glenn says there is some semantic inconsistency
   … we need to workout what that means

   pal: the computed value of tts:direction on a region can come
   from 2 different places
   … implicitly from tts:writingmode or explicitely if you specify
   it or initial value
   … I don't see why Glenn is unhappy

   nigel: it's not obvious is it?

   nigel: we need to ask glenn

   <glenn_> mainly, i

   <glenn_> mainly, i'm not happy with using a dull axe to cut out
   tts:direction semantics

   <glenn_> we went to a lot of trouble to define out
   tts:writingMode maps to tts:direction which maps to paragraph
   embedding level in UAX#9; there is no need to remove those
   semantics

   cyril: Since last time I did some research in our catalogue.
   … I found 2 things.
   … 1. I found more example of tts:direction being used on p, and
   not only from internal Netflix tools
   … but at least 2 external vendors who produce such content.
   … 2. The content I found has tts:direction on p, no writingMode
   on region, but textAlign on p, most usually "center".
   … I need to search for other cases where textAlign is not used.
   … I am really worried that if we make this change to indicate
   that direction does not apply on p, there could be an impact on
   these
   … Netflix external vendors.

   <glenn_> I am also unhappy with (read cannot and will not
   accept) deprecating.

   atai: coming back to the rendering question
   … what are the expectation of vendors when putting this value
   on p
   … what interpretation is done by the renderers
   … what should be the rendering

   <glenn> thinks nobody is reading IRC except me

   atai: I struggle to see how the situation could be worse if we
   remove applicability on p

   <glenn> cannot accept deprecation approach

   atai: because it seems implementation dependent

   nigel: there is a missing data
   … for the content that Cyril has found, that sets direction
   … presumably it is setting direction to rtl

   <glenn> what is the missing data?

   <glenn> you do realize that the bidi algorithm uses the
   character directionality?

   nigel: is there a common expecting rendering behavior that you
   would be expected and that would change if direction
   applicability is removed

   <glenn> ah, someone is reading....

   <glenn> sorry, i'm not on audio

   nigel: specifically, around what is implemented now vs any
   hypothetical implementation

   pal: a very general observation is that implementations prior
   to 2017 or 2018 of TTML, perhaps with the exception of ttv and
   ttpe, were terrible
   … In my experience, produced documents that today would be
   deemed not conformant

   cyril: Netflix has received plenty of documents prior to 2017
   that were fine

   <glenn> @pal have you used all implementations? i haven't

   pal: but what does direction mean then in these documents

   cyril: maybe that its equivalent to writing mode

   nigel: there is a stated meaning of direction p
   … I don't think anybody doubts that it sets the paragraph
   embedding level
   … if the result of this change meant that it no longer did
   that, then a bunch of text already out there, if you rendered
   it with a now conformant implementation, would render in the
   incorrect order
   … that wouldn't be right

   pal: that's not accurate

   atai: going back to what Cyril said, that it was clear what
   directionality on p, I can guess that they wanted to indicate
   that the content in the p had the direction indicate in the
   tts:direction attribute
   … especially to override the left to right direction because
   they did not specify writing mode
   … if we follow the text in TTML2 as of now, i.e. setting the
   embedding level, this has an effect on arabic and hebrew
   … because the neutral and weak characters would use it
   … the issue we are facing is how it is defined in TTML is that
   it separates the directionality from the inline progression
   direction
   … CSS3 does both at the same time while TTML2 does not
   … the problem is that most authors would expect that it behaves
   like CSS
   … either way there will be problems
   … and not the expected rendering from the authors

   pal: as an example where this is not clear is the case where
   you have arabic (rtl) but writing mode is set (ltr) and
   textAlign is set to center
   … in that particular tts:direction will have no impact
   … if it's pure arabic with no latin
   … so that's the case where somebody might set tts:direction
   thinking it would do something but it does nothing

   <glenn_> not true

   pal: because some think it may set the alignment but they use
   text align

   <nigel> nigel: Glenn please go ahead via IRC

   <glenn_> I would like to point out (yet agaiin)

   <glenn_> that tts:direction is used in two context with respect
   to tt:p

   <glenn_> and one context with respect to tt:span

   <glenn_> it is used with tts:unicodeBidi as a parameter

   nigel: I think that's well understood in the conversation

   <glenn_> i don't think so

   <glenn_> with tt:p it has two uses

   <glenn_> we need to know which context applies

   <glenn_> if we are talking about the use where it appears by
   itself

   <glenn_> then tts:direction only means set the default
   paragraph embedding level

   <glenn_> and that does have an impact

   <glenn_> it means something and has a visual interpretation
   w.r.t. neutral characters

   <glenn_> so I don't know why pal is saying it has no impact

   nigel: in Netflix cases, is tts:direction applying with
   unicodeBidi?

   cyril: no

   <glenn_> it has nothing to do with textAlign

   cyril: there is no unicodeBidi in my example

   <Zakim> nigel, you wanted to say that #1213 is the issue that
   implements Andreas's point

   <glenn_> I don't have the example in front of me

   <glenn_> I think the examplle I looked at DID have unicodeBidi

   nigel: I wanted to note that Andreas made a good pointε about
   the direction and CSS compatibility
   … and that's precisely issue #1213 and that is not implemented
   in this PR

   <glenn_> it had tts:unicodeBidi="embed"

   nigel: sorry, this is confusing
   … in this PR, I don't think it does that

   pal: the PR is compatible with CSS
   … because the PR proposes that the paragraph embedding level be
   set by the inline progression direction computed on the region
   … which in CSS would be set by direction

   nigel: I will close the queue on this to move on in the agenda

   atai: I agree with Pierre that the PR solves the conflict with
   CSS because it avoids the situation where TTML acts differently
   from CSS
   … but I also need to agree with Glenn that setting
   tts:direction to RTL and have centered arabic text as content
   in that p, will render different from the case where you have
   not set tts:direction on the p

   <glenn_> that is precisely the semantic inconsistency I point
   out in my comments

   <glenn_> tts:writingMode does not apply to tt:p

   atai: there have been some examples in the long long thread
   … where I mixed some latin text with weak characters and
   numbers, and this will be rendered differently
   … I'm not sure if we discussed the option that some parts of
   the rendering could be implementation dependent
   … I think that reflects the reality at the moment
   … at least regarding the setting the edges

   <glenn_> tts:writingMode applys to tt:region which has special
   semantics that flow to tts:direction which inherit down to tt:p
   which apply to paragraph embedding level WHICH NEEDS TO STAY AS
   DEFINED

   atai: saying that it's not clear in the spec and implementation
   dependent

   pal: I will withdraw my PR

   <glenn_> I support withdrawal of the PR, thank you pal

   SUMMARY: Pull Request is closed without merging due to lack of
   consensus

  TTML Profile Registry

   nigel: we published a new version, thank you very much Atsushi
   … it's a WG note, we can publish whenever we like
   … Cyril has made a request by email
   … to add in a new IMSC1.1 based profile
   … Mike expressed support for this already, which is helpful
   … there is no general reason why we would not accept it
   … the proposal I suppose is to use identifier nst1
   … not used at the moment

   PROPOSAL: add the Netflix profile to the TTML Profile Registry
   as requested using identifer nst1

   nigel: any objections?

   mike: no objection, I consider approved and closed, but I have
   a question
   … the process says to put it in the agenda and discuss
   … would we ever decline if the 5 items requested are provided?

   nigel: maybe there would be ways to misuse the process
   … the fact that it's a formality is not a concern for me

   mike: I thought it was administrative

   Resolution: add the Netflix profile to the TTML Profile
   Registry as requested using identifier nst1

   nigel: Cyril can you raise an issue?

   cyril: yes

  Patent Policy 2020

   gkatsev: I doubt that we really care that much
   … but it sounds like if we wanted to apply the PP2020 we have
   through nov 27th to say so and the charter would be updated
   just for that
   … so we could use the new PP immediately
   … otherwise we will have to wait for the next re-charter,
   december next year

   nigel: I haven't kept track of the differences

   gkatsev: the continuous CR living standard would require that

   nigel: and we have no plan to use that mechanism

   gkatsev: not right now
   … but I figure it's worth mentioning it now

   cyril: what's the harm in adding it now even if we don't use
   it?

   gkatsev: probably nothing

   nigel: anybody would have concerns about adopting it?

   <atsushi> could be helpful: [13]https://docs.google.com/
   presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/
   edit#slide=id.g9b7a7df111_1_47 (slide used for DID WG TPAC)

     [13] https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47

   nigel: I would advocate for using it
   … and for a reduced review period if there is this deadline of
   Nov. 27th period
   … Atsushi, can I ask you to extend the deadline to accomodate
   our decision review period
   … which would bring us to Dec. 3rd
   … I don't want to reduce the review period, because people may
   have to go back to lawyers

   atsushi: this seems to be a strict deadline
   … we can ask rechartering at any time

   nigel: I did not understand the deadline, causing AC review if
   we are too slow
   … I will ask plh directly if you want

   atsushi: the purpose is to make it easy to review multiple
   charters at the same time

   PROPOSAL: adopt Patent Policy 2020

   nigel: are there any objections now

   cyril: I don't know
   … I think it's ok but I will consult

   Resolution: adopt Patent Policy 2020

   nigel: If you think you need a review, please do it now, don't
   wait for the 2 weeks
   … it might be too late

  Default branch name

   Nigel: We don't have time to cover this now so I'll bump it up
   the agenda for next week.

   Pierre: Would like a proposal from the Chairs and W3M. It's
   going to be work whatever we do.

   Nigel: I think it is going to impact Editors primarily.
   … In any case, let's come back to it.

  Meeting close

   Nigel: Thanks everyone, we're out of time for today. [adjourns
   meeting]

   <atsushi> nigel: for branch name item, let me send some line of
   summary and proposal for changing procedure shortly (I hope
   shortly...)

Summary of resolutions

    1. [14]add the Netflix profile to the TTML Profile Registry as
       requested using identifier nst1
    2. [15]adopt Patent Policy 2020


    Minutes manually created (not a transcript), formatted by
    [16]scribe.perl version 124 (Wed Oct 28 18:08:33 2020 UTC).

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

Received on Friday, 20 November 2020 21:28:34 UTC