Meeting minutes
This meeting
Nigel: Today I've put TTML2 #1211 back on the agenda in case we want to discuss more.
… Also Virtual TPAC planning, and TTML Profiles Registry
… AOB?
group: [no AOB]
Interaction between tts:writingMode and tts:direction on paragraph element. w3c/ttml2#1211
Pierre: I'd like to discuss how we get to a resolution on this; it is blocking resolution of an
… issue on imsc.js
… What about if we pick a time and date and say "we're going to solve this on this time and date"
… and ask everyone to come in with all the input needed etc. Then at the end we'll pick
… something.
Nigel: Would it make sense to gather our best knowledge and then raise it in the joint meeting
… with the CSS WG?
Pierre: The answer should be yes, I'm hesitating because I am not a specialist in Arabic, Hebrew etc
… and there's a limitation on CSS; if that would be helpful I'm happy to ask the question on
… the CSS mailing list: explaining that direction in CSS sets the direction and writing mode,
… which Elika has already told me it is not a limitation but a feature.
Nigel: Also something we should ask internationalisation?
Pierre: We're unlikely to change CSS on this, there's a lot more international content in
… CSS than in TTML, so I doubt that we would change their mind without a compelling set
… of examples, which we don't. Glenn might be the best person to provide that, but he has
… not. I would tend to saying "do what CSS does" in the absence of the test content and
… examples to have a definitive opinion.
Andreas: Which specification can we target for a change here?
Pierre: TTML2, ultimately.
Andreas: OK, there was also the idea to constrain IMSC.
… The second thing is more a concern, from the current discussion, I think I understand
… how it was meant and how it should work, which may already help IMSC, and it should
… be possible to implement, but my concern is about how everything works together and
… that it is not explained enough in TTML. It is only in the reference implementation of TTPE
… and not in the spec.
Pierre: To make things worse it is broken in TTPE too.
github: https://github.com/w3c/ttml2/issues/1211
Pierre: So I am not super excited to consult CSS, we should use what's in browsers today
… and only ask for a change if we find a fatal flaw.
Nigel: Are you making a specific proposal to remove the application of direction to p?
Pierre: Yes, but I think it is not sufficient because setting it on span also changes the
… definition of start and end as Gary pointed out.
… I'm suggesting we pick a time, aim to solve within an hour and reach consensus.
… That gives everybody an opportunity to prepare.
… After or at TPAC, for example.
<atsushi> https://www.w3.org/wiki/TPAC/2020/GroupMeetings
Nigel: OK, TPAC dates are a little unclear, the obvious date range is 19-24 October.
… How about making it the main topic of our call on 8th October, the regular weekly call?
Andreas: We may need to extend the call
Nigel: I've created https://github.com/w3c/ttwg/issues/151 for that meeting.
Nigel: Any specific points about this issue to raise while we're here?
Cyril: Small point to clarify. Many times in our discussions we mentioned the semantic
… derivation and hinted that we could use the direction as a way to interpret the edge
… for padding and textAlign, and Glenn never responded to that part.
… My understanding is that they are not normative and that may be why he did not consider
… them at all. Is that true that they are not normative?
Nigel: I think so, need to check.
Cyril: Then we should be careful - it may mean the CSS writing mode reference is not normative.
Nigel: Yes, it's in Appendix N which Non-Normative.
Andreas: I think this is really the point. You say that it is semantically derived from those
… specs, but don't explain a lot in the spec itself, and then make the derivation informative.
… TTML has not sufficient text to explain the layout in general. It leans on XSL-FO but a lot
… of it is informative not normative so it is really hard to understand how this works together.
… For an implementer what should they do? Where should they check how it should work?
… Even if it is not normative, but there is a semantic derivation, there is some kind of dependency.
Nigel: N.2.1 says that it can be used for mapping to CSS or XSL, or to other things like SVG.
… I think the informative nature of these derivations is supposed to be a strength in that way,
… but sometimes it appears to be a weakness as well.
Cyril: I just wanted to alert the group about that.
Nigel: Thank you.
Virtual TPAC 2020 Planning.
Nigel: I think Gary, we haven't done our action, so let's slap our wrists and get on with it!
Gary: I haven't done it, no
Nigel: And Gary, you added the viewport issue to the list of CSS issues.
Gary: Yes
Nigel: There is a proposal from APA to meet with synchronised media groups on
… Tuesday, Oct. 13 from 14:00–15:00pm UTC (10:00 - 11:00pm EDT)
… I will respond to say yes, assuming no objections?
Add syntax of codecs parameter w3c/tt-profile-registry#78
github: https://github.com/w3c/tt-profile-registry/pull/78
Mike: 4 points, a couple are editorial.
Nigel: My plan for the concrete example was to have a separate pull request.
Mike: Sure, we should add it though, as we agreed last week.
Nigel: Yes, no problem.
Mike: Going through my comments.
… I thought it would be good to note that the element in RFC6381 prohibits "."
… It's not clear in RFC6381 but you can't add a "."
Nigel: I wanted only to add a constraint statement and not duplicate what's in 6381.
… We could describe 6381 but not redefine it.
Mike: I think 99% of readers won't go to 6381 so the prohibition of "." is worth calling out in a note.
… 2nd one is a bit of rewording.
Nigel: Good for me.
Mike: The concrete example using IMSC 1.0.1 and EBU-TT-D 1.0.1 would be valuable.
… And the 4th one is something about the formatting.
Nigel: The formatting looks good to me.
Cyril: It looks good to me too.
Nigel: That's weird, I stole the formatting from IMSC to make it look the same.
Cyril: There's a typo - I'll put a note on the line.
Nigel: OK sounds like there's a bit of work, but straightforward, thanks for the reviews.
SUMMARY: @nigelmegitt to do 2nd editorial pass
MIME parameters ("codecs") for bucket ISO BMFF-wrapped TTML versus "application/ttml+xml" w3c/tt-profile-registry#76
github: https://github.com/w3c/tt-profile-registry/issues/76
Nigel: Looks like there's proposed wording and an amendment that Mike is happy with.
Mike: I'll open a pull request.
Nigel: I'm a little confused about what grants the ISOBMFF codecs value the right to use
… our codecs parameter value as the third component.
Cyril: It's in the RFC, which points to 14496-12 and 14496-30 says the first term (sample entry)
… is stpp, the second is "ttml" and the third points to the profiles registry.
Nigel: That's clear, thank you. And it says specifically the "codecs" value?
Mike: Yes. The practical purpose is to signal indirectly via the parts in the MP4 file, which
… might be extracted into the DASH manifest to identify the media types.
Nigel: Thank you that really clarifies it in my mind.
Mike: Yes, it's the same parameter name, perhaps in hindsight we could have picked a different name, but it will work out.
SUMMARY: @mikedo to raise a pull request
Meeting Close
Nigel: Thanks everyone, we're out of agenda, let's have 13 minutes of our lives back! [adjourns meeting]