See also: IRC log
<scribe> scribe: nigel
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
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.
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?
github: 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
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> 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.
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]