- 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