See also: IRC log
<scribe> scribe: nigel
Glenn: [can only stay 45 minutes]
Nigel: Thanks for letting us
know.
... Any other time constraints from anyone?
group: [silence]
Nigel: Today we have TTML2 issues
if there are any for CR2, and any comments to be
... raised on the CfC.
... I should also raise the way that we are responding to
comments raised during the CfC period.
... I don't think we have anything on TTML1. Anything on
IMSC?
Pierre: There's one issue we ought to discuss, #372 re rw and rh, because you were surprised Nigel.
Nigel: Yes, let's add that.
Pierre: Also, based on feedback
I've received I'm about to open another issue against the
... requirements for rubyAlign which we could usefully discuss.
It's already there actually.
... Actually we already discussed rubyAlign so we don't need to
cover that.
Nigel: We have one action on CSS.
Glenn: I have a couple of issues
to discuss on TTML2.
... There are 5 pull requests approved pending merge.
Nigel: Let's come to that, just doing the agenda now.
Glenn: I have a couple of items on TTML2 to get to.
Nigel: I don't expect anything on
WebVTT. I haven't got a TPAC agenda item, but just to
... remind everyone registration is open.
... I've started to work on a list of topics to cover in a
potential joint meeting with the M&E IG
... which I will share.
... Anything else for the agenda today?
group: [silence]
Nigel: Ok let's go.
Nigel: Status report: CfC is more
than half way through and there are some pull requests
... that address comments received during the CfC period. I
want to treat those as CfC
... review comments and merge the fixes for those soon, but
alert everyone to the fact
... that is happening and encourage you to be aware when
reviewing.
... We have 5 approved pull requests pending merge, and I would
propose that we merge
... them as soon as possible.
... Any objections to doing that?
Pierre: Not an objection, just
confirmation that
... changes to the feature list are going to be treated
editorially, so we can make those
... changes prior to PR?
Glenn: I would support that.
Pierre: I thought we had discussed it.
Glenn: I think you could argue it
both ways. The feature system is on the one hand a
meta-feature
... in the sense that it is about features and it is not
defining new features but labelling them.
... On the other hand the standard profiles are normative so
every time we add or change
... one of the profiles files it is changing some normative
text in the document. I would
... prefer to take your point of view.
Pierre: I agree with your assessment.
Glenn: If we do it that way then
we should say that in the SoTD to give ourselves
permission
... to do that, which could result in objections from external
readers that we would have
... to deal with. We should raise that in the transition
request.
Nigel: The transition request has
gone through but we can amend it.
... I'm not hugely comfortable with this.
Pierre: If we are not comfortable
with it there may be alternatives but we should talk
about
... it because there's a significant risk that we may have to
modify features and the way
... they are formulated, just because of the sheer number of
them.
Glenn: Changing the feature list
is not adding or subtracting syntactic or semantic
... components of the specification.
Nigel: Here's a test: if an
implementation supported a feature and that feature
definition
... was changed then it could cause that implementation to
become non-conformant, so
... from that point of view it is a normative provision and the
change would be substantive.
Pierre: I agree.
Glenn: I agree.
Pierre: Then if we don't give ourselves that permission then what can we do?
Glenn: We can move it to TTML2
2nd Ed. We could note informatively that we intend to
... make certain changes but that due to timing we were not
able to do it in 1st Ed.
Nigel: Previously we tried to make editions non-substantive in change.
Glenn: It would have to go
through the CR process again.
... I wouldn't be surprised if we don't have other normative
changes given the large number
... of features.
Pierre: I understand the rules as
they're written right now, but this is pretty
inefficient.
... Refactoring features is highly unlikely in practice to
cause interoperability issues.
Nigel: I disagree.
Pierre: Can you point to such an implementation?
Glenn: Back to the point about
making implementations non-compliant, it depends on the
... implementation. If the implementation depends on the
override route, the first processing
... step of construct effective processor profile, then the
implementation can set it to
... whatever it wants. How many processors will not take that
route?
Nigel: We have to apply this rule
to content conformance and that is more likely to be
... affected.
Glenn: If you define a content
profile and use it for validation and then add a new
feature
... that could not have been prohibited but add that
prohibition based on the new feature
... then that's not going to be a problem. If you change the
semantics of existing designators
... then you may end up prohibiting syntax that was not
previously prohibited.
Nigel: If you're going to create
the content profile mechanism then you have to allow it
to
... be used safely.
Glenn: Ok. Clearly we can make
changes on the way to 2nd Ed if we go through a CR
process.
... So going back to the question about practical issue? I am
of a mind that it is very low risk
... in causing a practical issue.
Nigel: That may be true, but it's not the test.
Glenn: That's correct.
... If we have a consensus in the group we can present
that.
Nigel: Can I make a proposal that
we add a bullet to the at risk feature list to notify
readers
... that the definitions of feature designators may change. If
we can do that for features
... and then make the substantive change at PR then I'm willing
to see if we can do it for
... feature designators too.
Glenn: I like it.
... Just adding a #profile-version-2 bullet to the at risk list
might do it.
Nigel: My understanding is that
the at risk list is for features that can be dropped but
not
... changed.
Thierry: You're only allowed
"drop".
... If you change a feature and it is substantial then you have
to issue a new CR.
Nigel: Pierre, are you concerned
that you won't be able to complete a review of the TTML2
... feature designators during the review period?
Pierre: I expect to be done ahead of next week.
Nigel: In that case do we really need to worry about this?
Glenn: I'd be satisfied to not
change the at risk list and if we get a request to change
then
... use the standard route to deal with it, i.e. to add
informative text until the next edition.
Nigel: I think that might be the best way.
Glenn: We already have a changes
document. Eventually we will probably have a new section
... changes from CR2 to PR and by definition they would all
need to be marked as editorial
... but we could prominently point out editorial changes of
this type, that are warnings to
... the reader that something we found will be changed in the
near future.
Nigel: Sounds like a good idea to
me.
... I think we've circled round on this one and concluded that
we will take no action.
... Any other views?
...
... Ok that's a 'no' so let's move on.
... This arose from the question about merging approved pull
requests now. Any other
... questions or points on that?
...
... I'm taking silence as assent, so Editor(s) you can go ahead
and merge the following pull
... requests: #836, #842, #843, #844 and #845.
... Noting that 843, 844 and 845 are labelled
"substantive".
... Any more issues from you on TTML2 Glenn?
Glenn: No.
Nigel: The other point I wanted
to raise is that we're making change to the document
... during the CfC and it would seem fair to allow it to
stabilise. Are there any other
... pull requests expected?
Glenn: There's one for issue 830
and the other for 834 which tweaks the base-related
... features. It is going to involve adding a new feature
called #base-general. To make it
... consistent with other definitions and the ability to
prohibit the more general use of #base
Nigel: There are several editorial issues too.
Pierre: Glenn and I discussed 846
and realised it hadn't been opened as an issue yet.
... I expect to be done tomorrow with my review so hopefully
we'll be very close tomorrow.
Nigel: Can we set a target to merge all the pull requests by the end of tomorrow?
Pierre: Monday is more realistic.
Glenn: I agree.
Nigel: OK
... I issued the CfC on Wednesday 13th June, so end of Tuesday
is the end of the CfC.
... So that gives 1 day for final post-pull-request-merge
reviews before the end of the CfC.
... It's pushing the limits a little!
Glenn: Starting on the 26th, if
we finish merges on the Monday, I plan to do the normal
... pubrules and link checking which requires some minor tweaks
which will require at least
... one pull request. I'll need someone at hand to approve
those quickly so I can merge them.
... By the end of the 27th I need a package to send to staff
for upload for CR2 if it is going
... to be published on the 28th.
Thierry: The webmaster usually needs 2 days.
Glenn: If we get that done on the 26th would that be adequate?
Thierry: Yes it would be better
at the end of the 26th if you can submit a package then
... I can take care of it late on the Tuesday or early morning
Wednesday my time.
Glenn: OK I'll make that a date
then. I'll probably start doing the pubrules and have it
done
... by the 25th as well.
Nigel: That'd be good, thank you.
Glenn: I'll need help from another committer who can approve requests over the weekend.
Pierre: I plan to be around.
Nigel: With notice I will be able to also.
Glenn: If you could be able to
check your email once a day between now and Monday that
... would be adequate.
Nigel: Ok, with the proviso that
if there's anything strange or unexpected or complicated
... then I will probably block merging. We really need to ramp
down the significance of
... any changes from now on!
Pierre: +1 with a proviso that we
need to avoid substantial changes. But if there is a real
... blocker then it is not a reasonable answer to wait until
2nd Ed. especially if everyone agrees on the solution.
Nigel: If something substantive
does come up that needs a significant change then I would
... rather wait a few more days now than wait until 2nd Ed.
Pierre: Exactly.
Nigel: Included in the scope of
those changes to be merged as soon as possible is the
... branch with the updates to changes on that you were working
on Glenn.
Glenn: I can get that done by tomorrow.
Nigel: Then we can modify the transition request to point to the ED.
Glenn: [has to drop off the call]
Nigel: I think we had one issue to look at, #372.
github: https://github.com/w3c/imsc/issues/372
Nigel: My understanding of rw and rh was that they are beneficial especially with fontSize.
Pierre: Today you can achieve the
same effect using `c`. It's not pretty but you can
achieve
... that effect.
... We have discussed those requirements for many months and
nobody has suggested we
... add them. I think it is in the "too late" category. I'd be
more sympathetic if there were no
... other way to achieve it.
Nigel: Why are we too late?
Pierre: We are about to go to CR2 and there's a cost for supporting container related dimensions.
Nigel: A syntactic cost, given that the semantic is already feasible.
Cyril: It's not because it's been
there for months that we cannot change it. We have to
... acknowledge we have mostly been working on TTML2 to finish
it, so we should give
... ourselves some quality time to look again at the
requirements for IMSC 1.1.
Nigel: +1 My time has been taken up by TTML2 mainly and I would like that opportunity.
Pierre: There's a cost to
implementing it.
... So far nobody has made the argument why it is required.
Don't get me wrong, I think
... it might be useful, but just nobody has explained why it is
required.
Nigel: From my perspective the
requirement is driven by the errors that I see when QAing
... TTML documents that I see, where people get the %
calculations wrong.
Pierre: I don't expect anyone to adopt it.
Nigel: If it is absent from IMSC 1.1 then hypothetically EBU could not adopt it say in EBU-TT-D.
Pierre: If there were a liaison
from EBU saying they wanted it then it would make the
argument,
... but there is not one.
Nigel: I'm making this comment
from my own experience, that c units cause difficulties
... and we should move towards rw and rh.
Cyril: I don't want to take a closed decision now - I need time to think about this.
Pierre: If this is needed then it should be raised as an issue against the requirements.
Nigel: Arguably Stefan has raised this issue on the wrong repo.
Pierre: Cyril, if Netflix is
interested in adding rw and rh I ask that you do it super soon
so
... we can get it in and get it done.
Cyril: I don't think we need it but I will cross check today or tomorrow.
Pierre: Super. Nigel, if EBU has
IMSC 1.1 adoption on its roadmap and has strong feelings
... about rw and rh it would be good to know.
Nigel: I am not expecting any such statement.
Pierre: Or from anyone who plans to use IMSC 1.1 and has substantive input, now is the time.
Nigel: I've raised w3c/imsc-vnext-reqs#33 for this.
SUMMARY: Feature discussed, different viewpoints currently remain, requirements issue raised.
github-bot, end topic
Pierre: I'm making great progress
and should have something to present for review later
... today, refactoring the features table to match TTML2 and
fix some of the outstanding issues.
Nigel: Great! Did you have a view on the labels and colours question?
Pierre: Yes, I really liked where
you and Stefan ended up. I plan to implement something
... along the lines of what you have, putting the background
and rounded corners on the
... permitted/deprecated/permitted-deprecated label itself.
Nigel: Looking forward to seeing that.
Pierre: Thank you for doing all
the prototyping work, that makes it a lot easier.
... I plan to address that at the last moment when we are happy
with the features table.
... Can we talk about #366?
github: https://github.com/w3c/imsc/issues/366
Pierre: My impression is that we
have trained people not to use origin and extent on
content
... elements. Certainly in IMF and ATSC we have trained people
not to do it.
... imsc.js and TTPE and EBU-TT-D does not support it, so in
fact I think the trend has
... been the opposite, that we have reiterated that you cannot
do it. We have been saying
... that for the past 2 years and I'm finally getting to the
point where I'm not seeing it anymore.
Nigel: Now I really want to make
sure it is on the at risk list for TTML2 because I really
... don't want to support it.
Pierre: Based on my experience in
imsc.js the feature really breaks the way TTML was
... designed. Unless someone stands up to say they really want
it I don't think we should do it.
Nigel: It is not on the at risk list for TTML2 CR2.
Pierre: TTPE doesn't support it in TTML1, I'm not sure if it supports it in TTML2.
Nigel: Does anyone want to take
the action to raise an issue to add the
... `#region-implied-animation ` to the at risk list for
TTML2?
Pierre: I think it's reasonable to add it.
Nigel: If we can close this
meeting early then I'll go ahead and do that.
... Going back to the issue you want to only allow position on
region? Is that only on text profile?
Pierre: The same restrictions on tts:origin should be placed on tts:position, whatever those are.
Nigel: Don't you want position on image?
Pierre: You put it on the region that the image is in.
Nigel: And you only allow one image per region?
Pierre: Correct, just like in IMSC1.
RESOLUTION: We will not support `#region-implied-animation ` in IMSC 1.1.
Nigel: We also have another resolution to do what the issue requests.
RESOLUTION: Apply the same constraints that exist on `tts:origin` to `tts:position`.
github-bot, end topic
action-512?
<trackbot> action-512 -- Pierre-Anthony Lemieux to Raise an issue with css wg requesting support for lineshear -- due 2018-06-21 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/512
Nigel: The due date is today!
Pierre: Realistically I will not get to this for another two weeks or so.
Nigel: I've updated the due date to 5th July.
Nigel: We've completed our agenda for today, thank you everyone. [adjourns meeting]