- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 8 Jun 2017 16:22:51 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D55F37D7.419B5%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/2017/06/08-tt-minutes.html
Please note that we made a Decision to approve the proposed IMSC 1.0.1 CR exit criteria prior to publishing the CR. This falls within our Decision Policy however we have outstanding issues to dispose so we have not made a decision to publish CR yet. Nevertheless the next 10 working days would be the appropriate time to raise any issues with those CR exit criteria!
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
08 Jun 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/06/08-tt-irc
Attendees
Present
Nigel, Andreas, Mike, Thierry, Pierre
Regrets
Glenn
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]TPAC 2017
3. [6]IMSC
4. [7]TTML
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
Nigel: For today I think the main topics are IMSC, and moving
IMSC1.0.1 to CR, and TTML2
... is there anything else?
Thierry: TPAC
TPAC 2017
Nigel: The draft schedule has us meeting on Thursday and
Friday, with Web and TV IG
... on Monday, and CSSWG on Monday and Tuesday, with a
suggestion that we invite
... CSSWG for a joint meeting during our meeting at some time.
Thierry: Will the CSS WG be around on Thursday and Friday?
Nigel: We can ask!
<scribe> ACTION: nigel Invite CSSWG to joint meeting at TPAC
2017, with list of topics. [recorded in
[10]http://www.w3.org/2017/06/08-tt-minutes.html#action01]
[10] http://www.w3.org/2017/06/08-tt-minutes.html#action01
<trackbot> Created ACTION-497 - Invite csswg to joint meeting
at tpac 2017, with list of topics. [on Nigel Megitt - due
2017-06-15].
Nigel: I'd like to get a draft list of CSS features that we
would need for subtitle and caption
... presentation, arising from our work on TTML generally.
Pierre: For IMSC1 the obvious ones are multiRowAlign and
linePadding.
Andreas: What about line gap?
Pierre: Yes and that too now.
Nigel: I suspect Glenn and/or Dae will be able to list some
Ruby features too.
... It would be good to have CSSWG issues open for those too.
Pierre: Look at #218 on imsc, which indirectly indicates where
there is (not) CSS support.
... For example rubyReserve and rubyOverhang are not supported
in CSS. I think Dae did
... an initial pass at doing that so it probably makes sense to
start from there.
Nigel: Thank you I will do that.
IMSC
Nigel: What are our next steps to move to CR?
... Thierry, you collated some wide review feedback this week?
Thierry: Yes, since yesterday I need to do more updates because
Pierre has been answering
... more comments so I will continue to update that wiki page.
Pierre: My suggestion is to run down the list of issues.
[11]IMSC 1.0.1 Wide Review Comments collated Wiki page
[11] https://www.w3.org/wiki/IMSC1.0.1_Comments_tracker
[12]Add diff from IMSC 1.0.0 and update
substantive-changes-summary.txt #244
[12] https://github.com/w3c/imsc/issues/244
Pierre: This is trivial, there's not much to be said here.
... I'll take care of that at the last minute like last time.
... The next is:
[13]Recommended character sets considered harmful #243
[13] https://github.com/w3c/imsc/issues/243
Pierre: I have both a question of substance and of process.
This question came out of the
... i18n and we were not involved in the discussion being
filed. Part of the issue is there's
... been a misread of the specification, folk reading more into
non-normative text compared
... to normative text. My take is that this is a
misunderstanding, and I'm trying to find the
... best way to resolve the misunderstanding.
... There are two other i18n issues, which fall into a similar
category. How do we resolve those?
Nigel: Were they all filed by Addison?
Pierre: One was, the others by Richard.
Nigel: I'll invite Richard and Addison to attend this meeting
next week so we can talk through
... the issues and check we understand properly what their
thinking is.
Mike: We could raise pull requests to clarify the language.
Nigel: I agree, that was my thinking, but I'm worried that we
might not address whatever
... caused the misunderstanding, if we don't discuss it and
find out by conversation.
... I think it will be most effective if we find a way to
discuss this first.
<scribe> ACTION: nigel Invite i18n to discuss IMSC 1.0.1 issues
[recorded in
[14]http://www.w3.org/2017/06/08-tt-minutes.html#action02]
[14] http://www.w3.org/2017/06/08-tt-minutes.html#action02
<trackbot> Created ACTION-498 - Invite i18n to discuss imsc
1.0.1 issues [on Nigel Megitt - due 2017-06-15].
Pierre: In #243 I don't know what clarification can be made.
[15]Requirement to support certain Code Point #241
[15] https://github.com/w3c/imsc/issues/241
Pierre: My conclusion is we can improve the text to refactor
the recommendation to use
... certain metrics with the recommendations for certain
character sets. I don't disagree that
... the current text is not the most straightforward. I'm
reluctant to do this in IMSC 1.0.1, so
... since it is not exactly a blocker I would prefer to defer
it to IMSC2.
Andreas: The text is there and I think it is correct but could
be read differently so there is
... maybe no strict requirement to update it, though it could
help to do so. What would be
... helpful is if the reader is clear that the code points
listed are not ones for which support
... is mandatory, so it is just about the metrics. From the
text you could read that if you have
... this code point and render it then you should produce a
glyph sequence which is identical
... to the reference fonts. Maybe the edge case is that if
someone has no glyph in the font
... for the code point then he may nevertheless render it with
a substitute glyph. So if the
... condition is there (because the glyph is being rendered)
then the glyph sequence
... rendering must be identical to the reference font, which is
circular because it implies
... that the code point must be supported.
Pierre: There are two conditions - §7.3 Reference fonts only is
supposed to apply when the
... glyphs are supported.
Nigel: I never understood it that way.
Pierre: The reference font section §7.2 says which code points
should be supported. Then
... §7.3 says "if you're going to support a code point for a
reference font AND it is in the list
... in Annex A" then you must end up with the same result, but
it does not compel support
... for all the code points.
Andreas: Would it be possible to add explicitly a condition
that it only applies when all
... the code points are supported by the font used to meet the
reference font requirements?
Nigel: +1
Pierre: I don't think that would be controversial - it is the
intent already. I would be happy
... to clarify that.
... [adds a note to the issue] I will generate a pull request
that clarifies this.
[16]Clarify "All regions shall not extend beyond the root
container" #239
[16] https://github.com/w3c/imsc/issues/239
Pierre: There's a pull request open for that.
Nigel: I just added an approval for that (it was wording
suggested by me).
[17]Why exclude hebrew and arabic proportional reference fonts?
#237
[17] https://github.com/w3c/imsc/issues/237
Pierre: This is an i18n comment. I think we ended up rewording
one of the sentences and
... Nigel you suggested a tweak, so I'm tempted to generate a
pull request to use as input
... to our discussion.
Nigel: Makes sense.
Pierre: I will generate a pull request [adds note].
[18]Should the character sets be minimum *font* requirements?
#236
[18] https://github.com/w3c/imsc/issues/236
Pierre: The recommended character sets is worded as an
authorial requirement rather than
... a processor requirement. This occupied a lot of discussion
for IMSC 1 so I'm reluctant in
... IMSC 1.0.1 to change it into a processor requirement.
... I propose a "won't fix" for IMSC 1.0.1 and add it to the
list of things to discuss with i18n.
Nigel: Ok.
[19]imsc1-all.xsd has a bad pointer for SMPTE-TT schemas #235
[19] https://github.com/w3c/imsc/issues/235
Mike: The current IMSC 1 uses the SMPTE 2010 namespace and I'm
on a mission to develop
... some tight schemas for IMSC 1. When I started digging into
this I discovered that the
... backgroundImage wasn't documented until the 2013 namespace,
so if you were to try
... to write a comprehensive schema you would get stuck there.
It is trivial of course, as per
... the email I sent. The question is how to go about
addressing this. We could write to
... SMPTE and note that 2010 is missing backgroundImage, but
the answer would probably
... be to use 2013. Or we could write it ourselves but it would
be a little weird to write
... something in the SMPTE namespace.
... It would be disruptive to switch to the 2013 namespace
because it is incompatible
... with the 2010 namespace.
Pierre: To Mike's suggestion, we or SMPTE could conceivably
create a 2010 schema.
Mike: All we need is one attribute of type xs:anyURI.
Pierre: We either create that one definition and move on, or
get SMPTE to write it so that
... they have control of it.
Mike: There's maybe a hybrid where we ask SMPTE to do it but
offer to do the work.
Pierre: Or we could create it, send it to SMPTE and ask them to
publish it.
Nigel: This is informative only. [traces through the SMPTE
references]
Mike: There's an example in ST2052-1-2010 where
smpte:backgroundImage has a URI
Nigel: I see there's a substantive issue here in that the
normative specification isn't completely
... clear that backgroundImage takes a URI, though it can be
inferred. Possibly we need to
... add a clarification to IMSC1.0.1. On the schema, which is
informative I'm not so bothered.
Mike: That's why 2013 was done! I think it would be good to
clarify in IMSC 1 and offer a
... proposed update to the 2010 schema to include it. While
we're writing to SMPTE we can
... also ask to verify that it is supposed to be an xs:anyURI.
... I'll draft the liaison to SMPTE, and we ought not to touch
IMSC1 until we get an
... answer back and then there will probably be a follow-up
action to modify the spec.
Nigel: [adds note to issue]
Mike: Aside from this issue, the question I have for this group
is, if I write all these schemas
... and post them as a contribution, how do we attach them to
IMSC1?
Nigel: We can just add it to the linked documents we publish.
Another alternative is we
... could create a new repository just for the schemas and link
to that. It is much easier for
... people to use that way too.
Mike: Sounds good to me.
Pierre: +1
Mike: Then it provides a good way to update it in case any
changes are proposed later.
Nigel: Agreed.
... Should we add a new repo?
Pierre: The schemas are already in the spec repo. We could keep
it there as a directory
... and when it feels right to create a repo, do that. We can
do everything we want on a
... separate branch on the IMSC repo and when we're ready
create a separate repo.
Mike: I like the first part, maybe we don't need to create a
new repo.
Nigel: Okay, works for me.
[20]Recommend avoiding tab characters #232
[20] https://github.com/w3c/imsc/issues/232
Pierre: There's a pull request:
-> [21]https://github.com/w3c/imsc/pull/242 Discourage the use
of tab characters in <p> and <span> #242
[21] https://github.com/w3c/imsc/pull/242
Pierre: As you point out Nigel, it seems valuable to explain
this unusual exception. I also
... do not like informative text. Glenn seems to oppose it.
Nigel: Glenn says a note would be acceptable but bad practice.
Pierre: I'm happy to not have it, put it in the text or put it
in a Note.
Nigel: I prefer to put it in a Note.
Pierre: The text will say "should not use the TAB character"
and the note will say that no
... presentation semantics are specified for the code point.
NIgel: +1
Pierre: [adds note to pull request]
[22]Determination of the color in leading in tts:fillLineGap
#228
[22] https://github.com/w3c/imsc/issues/228
Pierre: I left the ticket open because we need disposition
comment from the commenter,
... but we have a conclusion in the group.
Nigel: Where did this come from originally?
Pierre: From the ARIB liaison.
Nigel: I believe that we only need to send a message back to
the commenter explaining
... the disposition, and offering a last opportunity to
comment.
Mike: We can send a link to the ED to make it easier, and to
the issue.
Nigel: Yes.
Thierry: We don't need to publish a new WD say.
Nigel: We have so few comments here I don't think we need a
tool.
Thierry: Yes, I think manually will be good enough. We can use
GitHub also, if the commenter
... adds a note.
Nigel: That's good for i18n say but not for ARIB.
Thierry: So for ARIB we will send an email.
[23]ittp:activeArea clarification #227
[23] https://github.com/w3c/imsc/issues/227
Pierre: this is in the same category as the previous one - we
have agreement here, and need
... to confirm the disposition.
[24]Create tests for CR exit criteria #226
[24] https://github.com/w3c/imsc/issues/226
Pierre: I created the tests, so I think we can close this.
Nigel: Can we review what the exit criteria actually are?
They're the same as we used for
... IMSC1, right?
<pal>
[25]https://github.com/w3c/imsc/blob/4f199de739945656838423d18f
f8df6235be4277/imsc1/spec/ttml-ww-profiles.html
[25] https://github.com/w3c/imsc/blob/4f199de739945656838423d18ff8df6235be4277/imsc1/spec/ttml-ww-profiles.html
Pierre: This has actually been merged into the ED.
<pal>
[26]http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html
[26] http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html
Pierre: It is the same as we used in IMSC1 but only applying to
new features.
Thierry: Looks good to me.
Nigel: The implementation report is a wiki page.
Pierre: Like for IMSC1.
Nigel: The Exit Criteria Test Suite is a 404.
Pierre: Yes that is because github.io won't let you browse
directories - it needs to point to
<pal>
[27]https://github.com/w3c/imsc/tree/4f199de739945656838423d18f
f8df6235be4277/imsc1/spec/exit-criteria-tests
[27] https://github.com/w3c/imsc/tree/4f199de739945656838423d18ff8df6235be4277/imsc1/spec/exit-criteria-tests
<pal>
[28]https://github.com/w3c/imsc/tree/master/imsc1/spec/exit-cri
teria-tests
[28] https://github.com/w3c/imsc/tree/master/imsc1/spec/exit-criteria-tests
Pierre: That directory has TTML files and PNGs.
Nigel: And the examples match what is in the spec for
fillLineGap.
Thierry: And there are just two.
Pierre: I think that is sufficient for this particular case.
Thierry: Yes.
Pierre: Especially since the fillLineGap test is pretty gnarly.
Nigel: Agreed.
... Any other comments?
group: [silence]
Nigel: Okay that's a decision to accept those proposed CR exit
criteria and test suite.
Thierry: If we need more tests we can add them later.
Pierre: [closes issue]
[29]Attribute syntax definition: missing spaces #221
[29] https://github.com/w3c/imsc/issues/221
Pierre: This is contingent on whether or not spaces are allowed
alongside delimiters in
... tts:fontFamily. I think we are getting close to a
resolution, so when we get there I will
... generate a pull request for IMSC1.
... I have not seen any comments back on the reflector about
this issue.
Nigel: Me neither.
Pierre: And Nigel and Glenn prefer option 2 so I think we will
go with that.
Nigel: If we have not had any more comments by this time next
week shall we just go with
... that option?
Pierre: Yes.
[30]Copy referenced schema to the schema directory for ease of
validation #212
[30] https://github.com/w3c/imsc/issues/212
Pierre: We are waiting on you for this Nigel. The last I heard
you were going to give it a try.
Nigel: When I tried this I got into all sorts of trouble but I
accept that it *should* work
... without copying the referenced schemas in.
... [closes issue]
Andreas: [leaves]
Pierre: That completes the review of IMSC 1.0.1 issues
scheduled for CR.
Nigel: So the next step is to complete the disposition with
i18n and write to ARIB about
... two issues. Thierry please could you find the usual
boilerplate, and send it to Pierre?
Thierry: Yes I will do that tomorrow.
Pierre: I will draft the email.
Nigel: Thank you both.
TTML
[31]Appendix R [June 4 ED] is overly constrained and does not
represent current best practice #384
[31] https://github.com/w3c/ttml2/issues/384
Nigel: I'm preparing a pull request for this.
... I'm concerned that progressive decoding is not always
possible.
Mike: My concern is that all of the text in the appendix should
be removed, so I'd like to
... start there, and then if someone argues the existing text
is fine then discuss that.
Nigel: That works for me.
... I plan to add a section referencing ISOBMFF and EBU-TT Live
explaining the temporal
... fragmentation approach used there.
Mike: I would like to take the TTML1 approach out and just
reference it as an alternative.
... Then this appendix is shorter. I know there's a document by
Cyril about this.
Nigel: Oh yes that's on github, written by Romain, Cyril and
me. We could reference that
... informatively.
Mike: I'm concerned about how stable that is though.
Nigel: Okay I understand, I'll submit a pull request along
those lines for review.
... I'll put a picture in too, because that's always helpful.
Mike: That sounds fine.
... And rather than perpetuate the fragmentation mechanism,
just point back to TTML1.
Nigel: Okay I'll make some changes and make that happen.
[32]Support for conditional styling. #128
[32] https://github.com/w3c/ttml2/issues/128
Nigel: I just want to check with you about this even in the
absence of Glenn.
... Is it okay not to be able to conditionally select a region
for content based on whatever
... input parameters are available? I think it might be because
the properties of the selected
... region can be conditionally set without having to choose a
whole different version.
... Otherwise we might end up needing to change the region
attribute to IDREFS.
Pierre: I need to see use cases for this otherwise I don't know
how to evaluate it.
Nigel: Makes sense to me. The way I'm thinking right now is
that using condition to support
... media queries (screen size) and user preferences (e.g. text
size) would be helpful, even
... in IMSC2 perhaps. But I'm not settled on a firm viewpoint
on that just yet.
Mike: I second Pierre's concern here that we need to understand
the requirements.
Nigel: Okay I agree that we need to address practical
considerations primarily, and I haven't
... any evidence so far to say that we should make any more
changes relative to what is
... present currently.
... So I will not open a new issue on this right now.
... On the issue of foreign namespace elements and where they
can go, we discussed
... it in the context of IMSC 1 and TTML1 but there's no issue
for it in TTML2 as far as I can
... see. Maybe one is needed.
... I'm hesitant to raise an issue without checking that there
actually is one, in case
... changes have already been made to TTML2.
Mike: I can do that right now.
Nigel: Thank you.
... I think we've run out of agenda, a little ahead of time, so
I'll close for today.
... Thank you all! [adjourns meeting]
/
Summary of Action Items
[NEW] ACTION: nigel Invite CSSWG to joint meeting at TPAC 2017,
with list of topics. [recorded in
[33]http://www.w3.org/2017/06/08-tt-minutes.html#action01]
[NEW] ACTION: nigel Invite i18n to discuss IMSC 1.0.1 issues
[recorded in
[34]http://www.w3.org/2017/06/08-tt-minutes.html#action02]
[33] http://www.w3.org/2017/06/08-tt-minutes.html#action01
[34] http://www.w3.org/2017/06/08-tt-minutes.html#action02
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [35]scribe.perl version
1.152 ([36]CVS log)
$Date: 2017/06/08 16:20:00 $
[35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[36] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 8 June 2017 16:23:25 UTC