See also: IRC log
<scribe> scribe: nigel
Nigel: For today, we will discuss
WR publication of the IMSC update.
... Then we have TTML issues, with some "focus" issues that
have already had some
... discussion on the reflector.
... I'd like to do some meeting planning too, in terms of
duration and start times, and also
... focus topics for upcoming TTML discussions.
... Is there any other business for today? Or any particular
points to cover that may not be on the agenda?
group: [tumbleweed]
Nigel: I'm on vacation for the
6th April, happy for the meeting to proceed if someone
... wants to volunteer to chair, scribe etc.
... I would like to propose we plan for 2 hour meetings on the
remaining April dates
... given our likely progress. Any views?
Dae: I agree.
Nigel: In that case I will
default to 10am Boston start time, 2 hour meetings in
April.
... For future TTML focus topics I will return to that in the
TTML agenda item.
Nigel: First, thank you Pierre for providing an updated version of the WD for WR for our review.
https://rawgit.com/w3c/imsc/WR-imsc-1.0.1/imsc1/spec/ttml-ww-profiles.html
Nigel: I raised an issue about security and privacy that we don't need to do now but should do soon.
https://github.com/w3c/imsc/issues/219
Nigel: There were two requests
from Glenn, firstly to change "minor revision" to
"revision",
... secondly to make a note about the possible change of
name/version in the future.
... There was also some discussion about adding a reference to
a change list in some form.
... At the moment the Scope summarises the changes but what is
needed is a little more detail.
... One option that other groups use is to link to an HTML
diff.
... Specifically I believe the change list is between this WD
and the IMSC 1 Rec, not between
... this WD and the previous WD.
Thierry: The goal for mentioning
those changes is to focus the wide review on the new
... features only, so therefore you should have the differences
between the WR WD and the previous Rec.
Nigel: Firstly then, any problems with removing the word "minor"?
group: No problems.
Pierre: That's straightforward to do, I can do that easily.
Nigel: We've had some discussion
about the addition of warning text about a possible version
change on the reflector,
... my personal view is it is not needed - there are a number
of bad things folk might do but
... I don't think any warning we put there will prevent them
from doing those things.
... Having said that I wouldn't have a strong objection to
it.
... Any other views?
Pierre: The likelihood that we will make the change is low so the addition is unwarranted.
Glenn: I view this as similar to marking features as risk. My position is we should add the note.
Mike: I think this matters to
those on the phone call, and others including those in W3C
probably do not care.
... I would lean towards leaving this alone and not adding the
note, and hope we do not need
... to discuss it again.
Nigel: Glenn will you object to a
proposal to publish this WD for WR without the additional
... warning text?
Glenn: No, as long as we have minuted this and the decision.
Nigel: In that case I will (as
Chair) call this in favour of publishing with minimal changes,
i.e.
... without the warning message, in the cause of
expediency.
... The third issue is about referencing a change set.
Pierre: The idea of providing the
reader with an unambiguous diff is really important.
... Viewers can do that themselves with the W3C diff tool.
Pierre: We could list the substantive changes, which would exclude the editorial changes.
Thierry: For simplicity I would
recommend using the diff tool. This can be done with a
link
... in the spec, or I can save the results in a file that we
can then link to.
... Let's make it simple, put a link to a file in the same
directory, and I will generate the
... diff file and upload it to the publishing directory.
Pierre: Okay then I will not
create a link to the W3C HTML diff service, instead I will
assume
... there will be a diff file included alongside and that will
be a diff against the Rec.
... And separately we have to create a list of substantive
changes?
Thierry: No, you don't need to do
that until we transition to CR.
... This is just to focus the wide review on the changes
only.
Pierre: §6.3.2 of the Process talks about substantive changes since the previous WD.
Nigel: We made a change to the way the Active Area is calculated.
Pierre: So I have to create that file, which will be straightforward.
Thierry: Then just list it in the appendix.
Pierre: I will do that.
Nigel: Ok that sounds like a
plan, the 4th and final thing is the Security and Privacy
section.
... My question is: do we need this now, or can we add this at,
say, CR?
Thierry: It would be better to
have it now, because we can ask the Security guys to
review
... that during Horizontal Review. It could save us some
problems.
Nigel: Actually we must ask for
that review, and they will ask us to fill in a form, and
that
... will ask us if there is a section present, and we will say
no, and they will say to create it then.
... Thinking practically, what do we need to put into the
section? Just the points that
... I made in issue 219? Are there any other points?
group: [No other comments]
Nigel: In that case I don't mind
drafting a pull request for this to allow us to review
and
... include, and move a bit faster overall. I wouldn't mind
Pierre doing to either (or anyone else).
Pierre: [concerns about adding an extra 2 week review delay before publishing WR]
Thierry: We could publish without
it, and then add it in 2 weeks and update the WR.
... I don't expect any feedback on this other than from the
security people.
... That would allow us to save a bit of time.
Pierre: I'm happy with that.
Nigel: Ok that works for me, to
go ahead without that section, rapidly work on that
section,
... and then publish when we have agreed an update.
... If people are willing to give positive comments on the pull
request sooner we could get it
... in by positive consensus.
... I could draft something by end of play today for review and
hopefully completion by end of play tomorrow.
Thierry: Would that be okay for
everyone? Then we could include it next week.
... I would rather people would positively agree before, but if
an issue is spotted then we
... could then make a subsequent update to the WR.
Nigel: OK let's try that and see
if we can make it work.
... Those are all the points to discuss, now I'd to move to a
proposal to publish.
... This would be a "mutatis mutandis" proposal.
PROPOSAL: After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.
Nigel: If we publish this next
week when will be the closing date for the review period?
... Sunday 7th May would be a little over 6 weeks.
Pierre: There will be external
organisations who may review, and some of those groups do
... not meet regularly, so we need to give them the opportunity
to reach consensus.
... I'll use Sunday 7th May.
RESOLUTION: After applying the changes agreed in principle in this meeting we will publish this draft of IMSC as a WD for WR.
Nigel: Thanks, that's all on IMSC, let's take 3 minutes and come back and spend the next hour on TTML.
Thierry: I have to leave now.
Nigel: I'd like to go through the
focus topics, agree next week's focus topics, then go through
any other
... issues anyone wants to discuss. Will that work for
everyone?
group: [assent by silence]
Nigel: First one is Inline Space
https://github.com/w3c/ttml2/issues/53
Nigel: Are we at a point where we
can agree that if the use case is micro-positioning of
... glyphs then that data is in fonts and we do not need to
support negative inline space?
Pierre: My data point is that
this has proven useful in digital cinema over many years.
... If we are planning to filter feature support based on
Lambda Cap then that would make
... things a lot simpler.
Glenn: Even though there may be a
problem to solve we do not need to solve it in the same
... way. The same problem as fillLineGap exists here in that
micropositioning can only be
... achieved if there is knowledge of the font used at
rendering time. We cannot require a
... sufficiently closed environment where that is known. So my
position would be not to add this,
... especially since other solutions exist such as use of
images.
Nigel: Can we make a group
disposition here that we will not support negative inline
... space for the purpose of glyph micro-positioning since
other mechanisms exist?
... I am thinking ahead to the response to the original
requester.
Pierre: I will not oppose that.
Nigel: Ok that sounds like a
decision as I described. I will add a note to the issue.
... I have taken off the "Editor considers closed" label and
closed the issue.
... The next issue is #239 3D and images
https://github.com/w3c/ttml2/issues/239
Nigel: We discussed this a little
last week but did not close it off because we wanted to
make
... sure all the right people were involved in the
decision.
Mike: I withdrew my suggestion, as was clear in the issue. I do not think this is needed.
Nigel: The only open question is
if we want named left and right parameters for use in
... the @condition mechanism.
Pierre: Why? What use case would this address?
Glenn: The named parameters would
allow for standardised approaches. There is no demanding
... requirement for this to be in TTML2. It could be added in
the future. In the meantime
... people could add extensions if they want them. There's no
provision in media queries
... for stereoscopic display targeting anyway.
Nigel: Let's draw the axe down on
this and do nothing, and close the issue. There's no
... requirement for it and we have plenty of other work to
do.
... I will add a note to the issue and close it.
... Done
... Next issue is 96: Specify date as well as hours, minutes
and seconds in time expressions
https://github.com/w3c/ttml2/issues/96
Nigel: The summary of this is
that there is a problem but we have no spec text to address it
yet.
... I don't know exactly what the solution should be or if we
should leave it for the future.
... One idea would be to permit ISO8601 format datetime values,
for example.
Glenn: My take on this was that
we would leave it for the future. ISO8601 processing is
... a little complex and can require knowledge of external
information.
... This would certainly have a testing impact. I did not want
to suggest a syntax.
... I don't mind if someone else wants to draft something.
Nigel: I don't think there's an
answer for this in SMIL.
... Is the reason nobody else has a comment on this that they
do not use clock times?
Pierre: Yes, that's my reason.
Glenn: SMIL does actually offer an ISO8601 based syntax as an alternative for begin, end and dur I guess...
<glenn> https://www.w3.org/TR/smil/smil-timing.html#Timing-WallclockSyncValueSyntax
Nigel: Thanks, that would make
sense as a solution in TTML when ttp:timeBase="clock"
... I don't think it would make sense in other timebases nor
would it support a "days"
... component in general time expressions.
... I don't mind taking the action to propose that syntax.
Glenn: If the proposal is to
adopt the SMIL syntax then I don't mind taking it from
there.
... What's the attitude of the group - do we want it or not? I
am ambivalent towards this.
Nigel: The group also seems to be
ambivalent but there is a strong use case in live
... scenarios, either for capture of text or for live
authoring.
Glenn: I think the phrase here is "without objection"
Pierre: Why not use UTC?
Nigel: UTC doesn't offer a date
either, and in fact the hours component is locked off so
cannot
... be used to express date when ttp:timeBase="clock".
Pierre: Alright.
Nigel: I've added a comment, and will change the labels.
Glenn: Just to mention that
syntactically this makes it easy to integrate because the
whole
... clock value including date is wrapped in a "wallclock()"
wrapper. It is syntactically easy
... to integrate in the current syntax.
Nigel: Thank you!
... The next issue is 160 use of offset-time expression in
smpte mode
https://github.com/w3c/ttml2/issues/160
Nigel: I think the problem here
is that there is no quantisation rule in case a time
expression
... does not evaluate to a frame value.
Pierre: Shouldn't we simply
restrict the permitted time expressions so they do not
have
... this problem?
Glenn: We have deprecated this in part in TTML2 but this is a corner case.
Pierre: Can we not say that it
was unspecified before, it is deprecated now, and we are
... leaving it unspecified.
Glenn: That would be fine with me.
Nigel: Where is the deprecation?
Glenn: It is at §12.3.1 at the end of that section.
https://w3c.github.io/ttml2/spec/ttml2.html#timing-time-value-expressions
Nigel: I see. Are there any
exceptions where even with the deprecation invalid
timecode
... frame values could arise? Looks like the answer is no from
the equations in I.3.
Glenn: As far as I am aware the deprecation covers all of the cases.
Nigel: Ok is everyone happy to do nothing on this?
Group: [no objections]
Nigel: Great, I will add a note
to the issue and close it.
... Done!
... Thanks, those were all the focus topics for this
week.
... Looking at next week, what would people like to focus
on?
Pierre: https://github.com/w3c/ttml2/issues/240
emphasis-position vs CSS text-emphasis-position +
Mongolian
... It sounds like we are nearly ready to get to an agreement
on this.
Nigel: That's on the list.
Pierre: Related to that is issue
#254.
... We should be able to close both together.
Nigel: Okay I'll add that to the list and let r12a know we plan to discuss this on next week's call.
Dae: Can we talk about the IMSC mapping/fallback/transform issue?
Nigel: Yes, thank you for putting
that draft together in the week as you promised, we will
... have that on the agenda for next week.
... Ok we need more for the list than that - if anyone has any
other suggestions over the
... next few days please email me.
... In the meantime, we had no AOB, so I will close the
meeting. [adjourns meeting]