See also: IRC log
<scribe> scribe: nigel
Nigel: Today we have this meeting
agenda bash, and topics including
... TTML1, TTML2, IMSC, CSS TTML Profile Registry.
... One item of AOB from me is a reminder that we are subject
to
Code of Ethics and Professional Conduct
Nigel: the reason for mentioning
this is because we had an incident this week in which
... at least a couple of people felt that we had not stayed
within this code.
... Of course that is not acceptable.
... There's a little more information at:
Positive Work Environment Home Page
Nigel: which also describes procedures.
Pierre: On that topic, were the people who it was felt broke the code of ethics informed?
Nigel: Yes
Pierre: Thank you
Glenn: I want to object to the
categorisation of expressions of frustration as violations
of
... the code of ethics and its a natural product of time
constraints, and I have not been
... informed of a violation of the code of ethics. A couple of
people expressed concern,
... Nigel did and Andreas did too, and that was it.
Andreas: I added a comment, now
deleted, which is fine because it was in response to
... a comment that was also deleted, because I found that a
comment from Glenn was
... breaching the CEPC defined by W3C. I don't think we need a
big discussion on this but
... from my side it clearly broke that and crossed the line and
I want to make it clear that
... this is not the way we work together. We need to follow the
guideline from W3C.
... This is not the first time I think that such red lines are
crossed, so I wanted to remind
... everyone on that. Okay, different people have different
views on what is harassment etc
... but it is clearly defined. I don't think there is any need
for escalation now, but we need
... to stay within it and be respectful regardless of
frustration or not.
Nigel: I think I was clear in a private email that I felt that the behaviour was bullying, and my reasons for that.
Glenn: I just wanted to note that there was no Finding here, if you want to escalate it go ahead.
Nigel: Like Andreas I don't feel
we need to escalate this now, but regardless of the
opinion
... of this event, it is worth reminding ourselves that we are
subject to the CEPC.
... Back to the look-ahead,
... In terms of agenda stuff, and look ahead, we have meetings
on 2nd and 9th August
... And then two cancelled meetings on 16th and 23rd August,
back on 30th August.
... I have an action to propose some dates when we should plan
for DST time changes,
... which I have not yet done.
... This is now we are basing the meeting time on UTC, which
therefore needs to be
... modified twice a year to minimise impact on members.
Pierre: Why are we making that change?
Nigel: This is in line with the AC direction of travel.
Pierre: I'm fairly sure that AC did not make a fixed resolution here.
Andreas: I was at the AC meeting
where this came up. There were reasonable arguments
... for it. It is really difficult if someone wants to join a
meeting from outside and see when
... it is and see when it is in Boston time. It is
uncomfortable to schedule without using
... a time zone converter. I brought this in and proposed it. I
don't think we need a long
... discussion on it. If someone objects we can stick to Boston
time. I would like to move to UTC
... but if there's an objection that is fine by me.
Pierre: Nobody in the world uses
UTC, so that forces everyone to check. London and Boston
... times do mean something. I'm not sure how the decision was
made and haven't seen
... a pointer to it.
Nigel: We aren't in a position to debate the AC decision here.
Pierre: Okay then I will happily raise it with the AC if someone can point me to the decision.
Glenn: I've been using Zulu time
for all kinds of scheduling for my lifetime. The military
... and radio hams use it so it is widely used. We decided this
already so we should not
... revisit it now. The group discussed it so we made a
resolution, at least there was no
... objection so far. Making it zulu means everyone is equally
dissatisfied.
Andreas: I agree with Glenn on
this, we had this discussion in two previous meetings
... and I heard concerns but no objections to that. My position
now is there is no decision,
... nobody forces us, it's on the group to decide based on the
recommendation.
... This group is free to decide, we don't need to wait for an
AC report. If someone
... objects to it then it is not worth spending more time on
it. I am happy either way.
Pierre: What will it change for
people on the West Coast. Can we be specific because
... some of us need to reserve slots in advance.
Glenn: For 2 days it will change.
Nigel: It's my action to go and
check the DST date changes and propose when we should
... change our schedules.
Andreas: In the past year, most
of the times I missed the meetings where in the US there
... was DST.
Pierre: For the past 5 years I have had my early mornings disrupted on Thursdays.
Andreas: Yes, unsociable times
are fair to comment on also. There were also suggestions
... of rotating times.
Nigel: We can separate the points
of switching the basis to UTC and the DST switchover
dates.
... UTC is easier because most people know their local time
relative to UTC but not other
... places' local time relative to UTC.
... In terms of DST I need to check the dates and impacts. The
default would be to make
... no change and stick with US DST dates, but it could be that
it's actually better for some
... people in the US if we go early/late for a couple of days a
year, I need to check.
Pierre: I'll wait to see what you come up with.
Nigel: And a reminder about TPAC
- it looks to me as though quite a few people have
... not yet registered, so please do so - it will cost more if
you do it after 31st July.
... In terms of the rest of this meeting, any specific topics
to cover or AOB?
Glenn: I'd like to cover TTML2 issue #919.
Pierre: I'd like to talk a little
bit about IMSC 1.1 test submission process.
... I'm looking for group input on how to make it better.
... I also want to schedule my review time for upcoming
specifications so I'd like to know
... the timelines.
Nigel: The CfC for TTML2 was opened on Tuesday so it is stable for review now.
Glenn: As Nigel pointed out the
scope of the review is limited to the changes that
... Nigel pointed out in the email.
Pierre: That makes sense.
... I was planning to do a diff.
Glenn: I just finished updating
the changes document too, which has a new section
... on CR2 -> CR3 diffs.
Pierre: Thank you so much.
Glenn: That reminds me there's an
old section in that changes document that allegedly
... shows the differences between TTML1 2nd Ed and TTML2 CR1,
but I think I need to
... go back and update it from TTML1 3rd Ed to CR1 and make it
relatively complete. I'll
... probably open an issue on that.
Nigel: Good point!
... In terms of our general publication timeline, Pierre
requested an overview of our
... upcoming publication schedule last week, which I took the
action for, and then realised
... this morning would be better done by Thierry if he can, so
I'm afraid I bumped that
... action along, and I'm sure you haven't had chance to do
that yet Thierry.
Thierry: Right, I'll work on that
today and tomorrow and send the full dates out for
... synchronising for Rec.
Nigel: Thank you.
<tm> https://ethercalc.org/no163r5i5dxv
Nigel: Thanks Thierry, I updated
that this morning, and it is picked up on a batch job
... once a day to generate a graph, which I don't have the link
to. Thierry if you can find that
... please send it too.
Project Management boards and reports
Nigel: We are just over half way
through our CfC to publish TTML1 3rd Ed CR2.
... We have no TTML1 issues or pull requests marked for the
agenda.
Pierre: I'm not aware of anything
we need to discuss. The main action item is to create
... those tests, and I think we're going to get there soon.
Nigel: Thank you.
... Are you in the process of creating them, Pierre?
Pierre: Yes, and I'll be
focussing more on this in the next couple of weeks so I'd like
to
... talk about process for IMSC.
Nigel: Okay let's talk about that
in the IMSC agenda item then.
... Just to be clear, are some of the TTML1 tests the same as
the IMSC tests?
Pierre: I use imsc.js to generate
the results, so yes.
... It is the same tool and many of the tests we have already
done to convince ourselves there
... is a problem, so yes.
Nigel: Glenn has requested that we discuss issue 919;
action-443?
<trackbot> action-443 -- Glenn Adams to Prepare a document showing mapping arib ruby extension features to ttml2 for use as a liaison document to arib. -- due 2018-07-05 -- OPEN
<trackbot> https://www.w3.org/AudioVideo/TT/tracker/actions/443
Nigel: I think you said you would do some kind of summary for us here Glenn?
Glenn: Right, I think I can get to that this week.
Nigel: Great, thank you.
Glenn: It will be in the form of
a summary showing the features TTML2 provides related
... to Japanese, and feel free to comment, etc.
Nigel: OK
... As mentioned earlier in the call, we have a CfC open for
TTML2 CR3.
CfC for TTML2 CR3 request for transition
github: https://github.com/w3c/ttml2/issues/919
Glenn: This issue was to define
the extent attribute for use on the isd syntax, which at
... this point I consider to be new and that it will be refined
over time. So I have avoided
... going too far down the path of defining constraints on
usage here.
... The problem here was that in appendix H of TTML2 we compute
all of the aspect ratios,
... the resolution of the root container region and the
document coordinate space for
... the extent of the root container region. In H.2 the
resolution computes a resolution in
... logical pixels near the beginning of processing, at least
before any time you need to
... make use of width or height of root container region, and
it stays that way during processing.
... If the author does not specify a tts:extent on the root
container element then the
... implementation puts in a value that it wants to use, for
example the SAR of a related
... media object, etc. So it always comes up with a number in
logical pixels to use there.
... That means when other measurements are expressed in the ISD
after going through
... the process of using computed style values those might be
expressed in pixels and
... be encoded as pixels as opposed to rw or rh. They might
have started out as rw or rh
... but the implementation might have expressed them as pixels.
We have made no
... assumptions about the units in the ISD. It may be
disadvantageous to do early
... translation to pixels, for example em, c units etc might be
in the ISD. In the absence
... of an extent attribute that records what the implementation
chose, then it becomes
... difficult to resolve them, or it would be done by the
receiving end.
... Nigel you commented that surely a pixel extent is not
required to compute rw or rh.
... That depends on what you're using them for. Maybe, or maybe
not. I wanted to comment
... on your question there.
Nigel: Thanks for that, I don't
disagree, and I think that a lot depends on the
processing
... model. Either way requiring extent on isd:isd would be
wrong in general, even though
... in some processing contexts it would be needed, so
constrained by the implementation.
... Indeed one approach might be to resolve dimensions into
canonical units and generate
... another ISD document based on an input ISD document, for
example.
Glenn: I just want to make sure we're on the same page.
Nigel: I think we are.
Glenn: I wanted to mention that
the condition attribute may also show up in the ISD
... for example, consider a case when you can only resolve a
condition at presentation time,
... or it is used at layout time and some parameter changes
from when the ISD was generated.
... In those cases you might have condition show up in the ISD
and whatever processes the
... ISD might have to do further processing on it.
Nigel: That raises the question
of if resolution of condition expressions can change the
... set of ISDs that can be generated?
Glenn: Sure, they absolutely can.
I think there's a note that evaluation of a condition
... might change results, and in that case the condition needs
to be propagated to the next
... processing stage, or something to that effect. In other
words, early resolution of
... conditions depends on the application and the semantics of
the condition expression.
... For example the parameter based system allows environment
defined parameters that
... are implementation-dependent.
Nigel: Right, so if an
implementation cannot resolve a parameter at ISD formation
stage
... then it needs to propagate that condition downstream until
something can resolve it.
Glenn: Right.
Pierre: My conclusion is it is
really not possible to evaluate rw and rh until there is a
known
... aspect ratio and I've not heard anyone disagreeing with
that.
Nigel: Yes
Glenn: I would amend that to say
a known resolution - the aspect ratios are an input to
... the resolution and the resolution is what is needed to
compute rw and rh units, as
... computed in appendix H.2.
... I also put in a note near the end of our CfC editing, in
one of the other issues,
... that reminds users that logical pixels do not have a
defined shape or size until they
... are mapped to display pixels, and I've done a better job of
defining inline terms that
... define logical pixel and display pixel and referring to
them elsewhere using links. Hopefully
... that will help readers.
SUMMARY: Discussion about dimension resolution in ISDs and condition evaluation, no changes needed to the spec resulting from this discussion.
Glenn: I'm back on test suites now, for the next couple of months.
Nigel: Thank you, we had a hiatus there for CR3 preparation (and holiday!)
Glenn: We have just under 2
months so we will have to work hard.
... If anyone has TTML2 related test materials they would like
to get in my queue for
... processing please send them to me, alert me to them
however.
Andreas: A comment regarding the
tests. Glenn, last meeting you said you would generate
... an overview that you thought could be finished by
today.
Glenn: Yes, that was overtaken by
events, and is on the top of my queue to generate a
... spreadsheet and put it up for that purpose, so people can
see gaps to help out with.
... I'll be doing that today and the next few days.
Andreas: Thank you
Nigel: First thing to note is that we published IMSC 1.1 CR2 today! Congratulations.
Nigel: I think Pierre wants to discuss the process for streamlining tests.
Pierre: I'd like to be able to
merge into the IMSC 1.1 branch more quickly, and then
allow
... us all to review together in one foul swoop. I think it
would be more efficient and would
... like the group to comment on that.
Nigel: How far through are we?
Pierre: We're nearly done. It
really extends the process if I have to wait for pull
requests
... to be merged.
Glenn: Is merge control turned on
on that repo? For example it is not turned on on the ttml2
tests repo.
... I would go along with Pierre and say take off the merge
control flag right now and later
... on when things get more stable the group can decide to turn
it on again.
Pierre: I would be happy with a 1 day review to make sure nothing horrible is happening.
Nigel: The 1 day review doesn't
ensure that - it might take 5 minutes to review, but it's
... about when you schedule those reviews, hence the 10
days.
Andreas: From my side it would be
okay to turn off the merge constraint for the moment
... for the test repo, not for the others, but for that one. 1
day review would be okay but
... not realistic.
... I'm sure if there's something to correct issues can still
be found.
Pierre: Don't get me wrong, if someone wants to review PRs I think we can turn them back on.
Nigel: What I would propose is
that we relax the merge control until Pierre you tell us
that
... the test repo is essentially done and then turn the merge
control back on.
Pierre: That works, and by the
way the work is happening on a branch so there's no
... action to take right now. I just don't want anybody to be
surprised by changing this without discussing it.
Nigel: thank you.
... I think we have consensus to allow the tests to be merged
quickly on the basis that
... when the tests are essentially complete Pierre will tell us
and we can a) begin a complete
... review and b) if necessary switch on merge control.
... I guess at some point we'll have a formal pull request into
the master branch that
... we will formally review.
Pierre: Exactly.
group: [discussion of tt:image test, resulting in filing https://github.com/w3c/imsc-tests/issues/66]
Pierre: The only tests I'm really
looking for input on are for rh and rw. There are a lot
of
... tests that need to be created so I'm looking for
contributions to that.
Nigel: I sense this comes to me, so I will schedule some time to prepare those.
Pierre: And Cyril, right!
Nigel: Yes, good point, I will liaise with Cyril!
Nigel: This is stable, we should publish it, shouldn't we?
Pierre: Yes, there are two
editor's notes that need to be tweaked in the light of CR2
so
... I will go ahead and create a pull request for that, then we
should publish it.
Nigel: That would a WG Note.
PROPOSAL: Publish the IMSC vNext Requirements as a WG Note
Nigel: I'm assuming we'll do a
quick pass to check it and address those editorial notes
... because we'll likely never come back to this document.
Pierre: The notes are related to
the at risk features, so we could either
... 1. Remove the notes, and then have requirements that are
ultimately not matched by the final spec
... because no implementations are presented, which means they
probably go to vNext.
... 2. Have notes in the requirements noting that they are at
risk in CR2. The problem there
... is that it is pointing to a specific version of the spec
which is not ideal.
Nigel: The third approach is to classify them as "really want these but can live without them"
Pierre: It's not clear with shear
vs lineShear because there's uncertainty, both in terms
of
... the best implementation and the demand. We could label them
"at risk", right?
Nigel: I think for shear and
lineShear we need to say "we want one of these but we're
not
... sure which one"
Pierre: That's what it says now,
but not for rw/rh, and for that one we might want to mark
... it as nice to have but not required, maybe.
Nigel: Okay, I will propose some
wording in a pull request.
... I've raised https://github.com/w3c/imsc-vnext-reqs/issues/37
RESOLUTION: After resolving the open issues marked as IMSC1.1, publish the IMSC 1.1 Requirements as a Working Group Note
Nigel: (checks that there are no objections)
Pierre: I have not yet raised the issue for support for lineShear
Nigel: There has also been discussion about background drawing:
Extruding border corners (negative border-radius)
Nigel: Raising for interest in the group.
Nigel: I added this agenda topic
because it feels like we have some new profile to add,
... or will soon.
... For example we have TTML2, IMSC 1.1, and IMSC 1.0.1
Pierre: It occurs to me the way
to address the chicken-and-egg is that MPEG will want
... to be able to get inspired for the IMSC 1.1 profile
designator, so I think it's better to do
... it early rather than late.
NIgel: Right, it seems that there
are changes for us and for others.
... This would be a good opportunity to prompt Frans to see if
there any EBU updates to make.
TTML Profile Registry repo issues
Pierre: Also what about Mike's point about content profiles vs processor profiles
Glenn: Where's that?
Nigel: I can't recall
Pierre: Me neither, but it should be captured somewhere.
Consider how to handle Content Profiles vs Processor Profiles #38
Pierre: It's pretty simple, now
we have them defined in TTML2 the Profile Registry should
... mention that.
Nigel: Yes, I think so.
... Formally IANA needs processor profiles, so the question is
for us whether we want
... to add content profiles in addition.
... We probably don't really have to, but it might be a good
idea.
Glenn: I just created an issue to add TTML2 profiles since they are not there right now.
Nigel: Thank you!
... I've added IMSC 1.1 profiles as an issue
... And one to update the IMSC 1 refs to IMSC 1.0.1
Glenn: Does IMSC 1.1 update the profile designator URI?
Pierre: Yes
Glenn: OK.
Nigel: I encourage everyone to
have a look at the Profile Registry and raise any change
... requests as issues on the repo please.
Nigel: Thank you everyone! We meet again same time next week. [adjourns meeting]