- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 19 Nov 2020 17:30:58 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <VE1PR01MB61431F7A0C3F9E2B19012667CAE00@VE1PR01MB6143.eurprd01.prod.exchangelabs>
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 Thursday, 19 November 2020 17:31:16 UTC