IRC log of tt on 2016-01-07
Timestamps are in UTC.
- 15:00:01 [RRSAgent]
- RRSAgent has joined #tt
- 15:00:01 [RRSAgent]
- logging to http://www.w3.org/2016/01/07-tt-irc
- 15:00:03 [trackbot]
- RRSAgent, make logs public
- 15:00:03 [Zakim]
- Zakim has joined #tt
- 15:00:05 [trackbot]
- Zakim, this will be TTML
- 15:00:05 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 15:00:06 [trackbot]
- Meeting: Timed Text Working Group Teleconference
- 15:00:06 [trackbot]
- Date: 07 January 2016
- 15:00:59 [nigel]
- Present: nigel
- 15:01:01 [nigel]
- chair: nigel
- 15:01:03 [nigel]
- scribe: nigel
- 15:01:15 [glenn]
- glenn has joined #tt
- 15:01:45 [nigel]
- Present+ glenn
- 15:02:40 [nigel]
- Regrets: tmichel
- 15:03:25 [nigel]
- Topic: This Meeting
- 15:04:57 [atai2]
- atai2 has joined #tt
- 15:04:57 [nigel]
- nigel: Next week David Ronca from Netflix has agreed to present what he couldn't at Sapporo,
- 15:05:07 [nigel]
- ... so I'd like to propose a 2 hour meeting so we can do that and normal business.
- 15:05:14 [nigel]
- ... i.e. on 14th Jan
- 15:08:12 [nigel]
- nigel: For today I propose we look at Actions, IMSC CR3 and issue #111 and TTML2 Editorial Actions.
- 15:08:20 [nigel]
- ... Also as AOB, more on the Emmy award.
- 15:08:25 [nigel]
- ... Any other AOB?
- 15:08:42 [nigel]
- group: no AOB
- 15:08:55 [nigel]
- Topic: Action Items
- 15:09:00 [nigel]
- action-451?
- 15:09:00 [trackbot]
- action-451 -- Thierry Michel to Investigate if we are required to move to the 2015 process -- due 2015-12-03 -- PENDINGREVIEW
- 15:09:00 [trackbot]
- http://www.w3.org/AudioVideo/TT/tracker/actions/451
- 15:09:31 [nigel]
- nigel: The objection deadline passed on the call for consensus so we have moved to 2015 process.
- 15:09:35 [nigel]
- close action-451
- 15:09:35 [trackbot]
- Closed action-451.
- 15:11:56 [nigel]
- atai2: I pushed some corrections of the drafts relating to fonts and mapping and the feature problems reported by Pierre and Simon.
- 15:13:16 [nigel]
- nigel: Please could you review your actions on tracker and if there's any update or a move to a github issue add the info and mark the action as pending review or closed?
- 15:13:55 [nigel]
- atai2: Okay, I'll update them.
- 15:13:59 [nigel]
- nigel: Thanks!
- 15:14:54 [nigel]
- Topic: IMSC CR3 etc
- 15:15:29 [nigel]
- nigel: I'd like us to look at issue #111 if we can - we have a good set of people here to talk about this.
- 15:15:49 [nigel]
- https://github.com/w3c/imsc/issues/111
- 15:16:03 [mike]
- mike has joined #tt
- 15:16:26 [nigel]
- glenn: Pierre and I had a talk about this and that resulted in a modification to my proposal that would allow me to remove the objection.
- 15:18:41 [nigel]
- pal: One way is to give control to Glenn on Webex to review/edit the solution live?
- 15:19:40 [nigel]
- nigel: Just checking everyone can see a shared screen?
- 15:19:46 [nigel]
- group: No objections.
- 15:20:53 [nigel]
- glenn: [shares screen showing proposal text]
- 15:21:54 [nigel]
- glenn: The main objection was that a processor that can work with both profiles simultaneously needs to
- 15:22:21 [nigel]
- ... make a decision on what profile to apply.
- 15:22:31 [nigel]
- q+ mdolan to ask about premises
- 15:23:05 [nigel]
- glenn: Implementors might choose either text or image profile and implement only one of them, in which case there's no decision point.
- 15:23:25 [nigel]
- ... However if you're implementing a processor that operates in a mode that only supports those two profiles then you need to make a
- 15:23:43 [nigel]
- ... decision with one of two answers, either text or image profile. Other possibilities I consider out of scope, for example a processor that
- 15:24:04 [nigel]
- ... can handle an arbitrary set of TTML profiles. This document is not interested in or defining or discussing that usage in the larger context.
- 15:24:11 [nigel]
- ack mdolan
- 15:24:11 [Zakim]
- mdolan, you wanted to ask about premises
- 15:24:33 [nigel]
- mike: An observation: in the known specification and implementations of the predecessor and IMSC 1 the decoders all support both
- 15:24:58 [nigel]
- ... profiles but don't rely on any sort of intermediate Y in the train tracks. The external signalling defines one or the other.
- 15:25:19 [nigel]
- ... The scenario is an implementation possibility but the issue hasn't come up because the switch in the train tracks was signalled at a higher level.
- 15:25:38 [nigel]
- glenn: I account for that internally. I'm dealing with the situation where there is no external information, and the processor is not
- 15:25:57 [nigel]
- ... implementing a sniffer and there is no external metadata and I'm trying to resolve the ambiguity that in the absence of any external
- 15:26:16 [nigel]
- ... profile metadata or preprocessor that guesses it then there is such a fork in the processing path. I only want to deal with the fallback
- 15:26:20 [nigel]
- ... default scenario here.
- 15:26:40 [nigel]
- mike: In this case, unlike perhaps the other TTML1 profiles, it's not the case that IMSC 1 Text and IMSC 1 Image are subsets of each other
- 15:26:58 [nigel]
- ... so treating them like the TTML 1 profiles where that processing can be done this is different.
- 15:27:18 [nigel]
- glenn: I'm not arguing that. I'm interested in 2 kinds of processing. For validation if you don't know what kind of profile you're validating
- 15:27:35 [nigel]
- ... with then it's not useful to proceed. I'm addressing a presentation processor case where you build a presentation engine that can
- 15:27:55 [nigel]
- ... support both of the two profiles and in doing so makes a decision on which profile applies to perform constraint processing during the
- 15:28:14 [nigel]
- ... presentation process. That can be provided externally by the document interchange process, using sniffing or envelope or context, or
- 15:28:31 [nigel]
- ... in the absence of that there needs to be a decision made. This harks back to the fact that TTML1 and TTML2 both define such a fallback
- 15:28:55 [nigel]
- ... default normatively. In TTML1 it is the DFXP transformation profile. TTML2 has a more complex algorithm using the version parameter
- 15:29:13 [nigel]
- ... and other information and chooses between a default in the TTML 1 profile space or a default in the TTML2 profile space.
- 15:29:23 [nigel]
- ... Both cases define a fallback default.
- 15:29:57 [nigel]
- glenn: In that case, I have an implementation that makes such a decision, and it's my perception that the specification is ambiguous and it
- 15:30:05 [nigel]
- ... should be possible to define a fallback default like TTML1.
- 15:30:15 [nigel]
- mike: In TTML1 the fallback is trivial - it's full.
- 15:30:23 [nigel]
- glenn: That's not the default - it's transformation.
- 15:30:35 [nigel]
- mike: It's easy because there are no extensions and all profiles are strict subsets.
- 15:30:56 [nigel]
- q+ to ask why a processor needs to make this decision
- 15:31:25 [nigel]
- mike: Normally people think about profiles as subsets - in this case it's a subset plus extensions so the fallback breaks down in this case.
- 15:31:47 [nigel]
- glenn: TTML1 does support extensions so I don't see how IMSC does something different in this regard. The defaulting algorithm
- 15:32:04 [nigel]
- ... doesn't take into account profiles outside its own space - you're right there. The only point in having a fallback default is to resolve
- 15:32:32 [nigel]
- ... the specification ambiguity in a formal way. If you leave it undefined I perceive that as being a hole in the specification, that it says A OR B
- 15:32:43 [nigel]
- ... and doesn't provide guidance as to making the decision.
- 15:33:05 [nigel]
- pal: Do you agree that if the image and text profiles were in two specifications then that statement would not apply?
- 15:33:29 [nigel]
- glenn: It wouldn't apply to either of those documents, correct. But they are both in the same specification so it is not relevant.
- 15:33:50 [nigel]
- pal: I think it is relevant because it's an artefact of the profiles being in the same specification.
- 15:34:52 [nigel]
- ack nigel
- 15:34:52 [Zakim]
- nigel, you wanted to ask why a processor needs to make this decision
- 15:35:14 [nigel]
- nigel: Why would you want to do "constraint processing" here given that a processor that can process documents in either profile
- 15:35:45 [nigel]
- ... must logically support the union of features needed to process all features, so why would you need to make the decision?
- 15:36:05 [nigel]
- glenn: There are a number of options for what to do and which rules to use, depending on which profile is in place. If as part of your
- 15:36:25 [nigel]
- ... presentation process you are paying attention to the constraints but not validating for the purpose of aborting if not valid, or notifying
- 15:36:43 [nigel]
- ... the user of problems then you have to pay attention to which constraints apply. In some cases the constraints are common to both
- 15:37:02 [nigel]
- ... profiles, such as the use of different metrics, and there are per profile constraints defined in §7 and §8.
- 15:37:15 [nigel]
- ... You need to know which rules apply.
- 15:39:06 [nigel]
- nigel: I'm confused still - what behavioural differences would arise if a non-conformant document were processed?
- 15:39:24 [nigel]
- glenn: The differences would depend on which profile applied. In the absence of any external information then it has to have a default.
- 15:39:49 [nigel]
- ... I made the text profile the default fallback because it seemed least likely to be a false positive. The only case is an image profile document
- 15:40:34 [nigel]
- ... that contains no indication that it is an image profile document.
- 15:41:30 [nigel]
- mike: I'm still not sure I agree with the premise but I'd like to see what you're proposing.
- 15:41:36 [nigel]
- glenn: Let me take you through it.
- 15:42:09 [nigel]
- glenn: [add terminology for single profile processor and multiple profile processor]
- 15:42:39 [nigel]
- pal: I just want to make something clear - the multi-profile IMSC processor is one that ONLY supports both IMSC processors and no others?
- 15:42:42 [nigel]
- glenn: Right.
- 15:42:46 [nigel]
- pal: And nothing else?
- 15:43:09 [nigel]
- glenn: That's correct. Further down I specified a note that the determination of processing of an arbitrary document instance not compatible
- 15:43:29 [nigel]
- ... with either profile definition here is out of scope. It wasn't my intent to handle a truly generic processor. That's an uber problem that
- 15:43:35 [nigel]
- ... could be specified elsewhere if we wanted to.
- 15:44:59 [nigel]
- nigel: What do we do with an SDP-US or SMPTE-TT document that in all other respects than the profile indication is IMSC conformant?
- 15:45:02 [nigel]
- glenn: I'll get there.
- 15:45:43 [nigel]
- glenn: The #profile feature in §6 as agreed in Sapporo needs to be referenced in the defaulting algorithm so I elevated that text into this
- 15:46:00 [nigel]
- ... proposal without any change in it. Where it says [profile specification] that's the same text as agreed in Sapporo.
- 15:46:32 [nigel]
- ... Then the meat of the proposal under the [profile defaulting] section describes what a single profile processor and multiple profile processor
- 15:46:35 [nigel]
- ... should do.
- 15:47:05 [nigel]
- ... [single] - if profile designator doesn't match processor profile then document processing may be aborted
- 15:47:34 [nigel]
- ... [multiple] - too complex rules to summarise in minutes
- 15:48:55 [nigel]
- mike: A comment: I think the context in a single profile processor will be clear - the real issue is for the multiple profile processor.
- 15:49:22 [nigel]
- ... The choice of default to the text profile is not based on a good decision tree because the probabilities of text or image seem equal.
- 15:49:44 [nigel]
- glenn: You're correct. You could say it's a random choice, but I tried to choose one that I thought would be more likely compatible, because
- 15:50:15 [nigel]
- ... it's more likely compatible with EBU-TT-D. I was trying to reduce the number of false positives and negatives and I thought the text profile
- 15:50:34 [nigel]
- ... would do a better job in some scenarios. The case where it would be wrong is if a document is image profile and the algorithm chooses
- 15:50:39 [nigel]
- ... to process as a text profile.
- 15:50:55 [nigel]
- mike: What does "tentatively" mean? Does it imply a SHOULD?
- 15:51:15 [nigel]
- glenn: I use the term to intentionally weaken the language and to make it possible for the implementation to make more choices.
- 15:51:31 [nigel]
- ... An implementation could choose the image profile - that wouldn't follow the recommendation but would be permitted.
- 15:51:37 [nigel]
- s/term/term SHOULD
- 15:52:09 [nigel]
- glenn: By tentatively I mean that if the wrong decision is made then abort would be an option, or retry with the other decision.
- 15:52:15 [atai2]
- +q
- 15:52:22 [nigel]
- ... When it is processing it is working on a guess.
- 15:52:30 [nigel]
- ack atai2
- 15:52:36 [nigel]
- ack atai
- 15:53:03 [nigel]
- atai2: It is strongly recommended to signal the profile or give information in the context. You have the probability of making the right
- 15:53:15 [nigel]
- ... choice by using text profile but you have no fact to base the decision on.
- 15:53:33 [nigel]
- glenn: Keep in mind that when it says "compatible with" I tried to avoid language that would strictly pin the language to a processor profile
- 15:53:52 [nigel]
- ... as defined in TTML1 because IMSC mixes the specifications of content and processor profiles. You're right. The way to have this default
- 15:54:52 [nigel]
- ... apply is to ensure there is some indication of profile, but the intent of this language is to encourage it.
- 15:55:18 [nigel]
- nigel: I can't see behavioural differences for processors based on the profile - what practical difference does this make?
- 15:55:51 [nigel]
- glenn: If you're using vertical writing mode that violates the constraints of the image profile - so what should the processor do? It can only
- 15:56:19 [nigel]
- ... decide whether to abort or ignore if it knows the profile. I agree there are few explicit normative statements that define behaviour. The
- 15:56:42 [nigel]
- ... only one I can think of off hand is the UAX14 line breaking algorithm. The definition of behaviour on non-compliance is undefined, which
- 15:57:05 [nigel]
- ... makes it hard to interoperably test content in my estimation. The processor needs an indication of what to do.
- 15:57:30 [nigel]
- mike: I agree with Andreas, a recommendation saying that a recommendation or strong encouragement to use profile is helpful, and further,
- 15:57:56 [nigel]
- ... on discovering that it's not a text profile then you should try the image profile rather than aborting. I would then probably be happy with
- 15:57:59 [nigel]
- ... this.
- 15:58:21 [nigel]
- glenn: A strong recommendation to mark or signal externally the profile would be fine. I could add that.
- 15:59:07 [nigel]
- ... On discovering a profile incompatibility switching profile - is that what you meant?
- 15:59:31 [nigel]
- mike: Yes, I think you want to encourage all possible efforts to try the correct presentation even if you discover an element or attribute that
- 15:59:41 [nigel]
- ... doesn't fit the profile would be better.
- 16:00:03 [nigel]
- glenn: If I were to change the note about potentially aborting would that help?
- 16:00:15 [nigel]
- mike: Yes, where "try the other profile" is the preferred option.
- 16:01:13 [nigel]
- nigel: We're out of time - I don't think we've handled the SDP-US or SMPTE-TT issues.
- 16:01:30 [nigel]
- glenn: I'll work on this in the meantime and we could maybe deal with that next time?
- 16:02:01 [nigel]
- pal: I'll review the revised proposal. Something I think will need to change is the name of the multi profile processor. It needs to be
- 16:02:26 [nigel]
- ... explicit that it supports only those two profiles, e.g. an 'exclusive multi-profile processor' or something similar.
- 16:04:33 [nigel]
- nigel: Summarising, we need to review a revised version of this and discuss again next week.
- 16:04:48 [nigel]
- glenn: I will post the proposal as a message to the public reflector.
- 16:05:18 [nigel]
- nigel: Thanks all, I'll close the call now [adjourns meeting]
- 16:05:34 [nigel]
- rrsagent, draft minutes
- 16:05:34 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 16:06:43 [nigel]
- Present+ andreas, mike
- 16:06:50 [nigel]
- Present+ pierre
- 16:06:56 [nigel]
- rrsagent, draft minutes
- 16:06:56 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 16:07:36 [nigel]
- s/about premises/about the premise
- 16:07:37 [nigel]
- rrsagent, draft minutes
- 16:07:37 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 16:11:01 [nigel]
- s/+q/q+
- 16:11:03 [nigel]
- rrsagent, draft minutes
- 16:11:03 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 16:12:08 [nigel]
- s/recommendation saying that a recommendation/recommendation/
- 16:12:13 [nigel]
- rrsagent, draft minutes
- 16:12:13 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 16:13:14 [nigel]
- ScribeOptions: -final -noEmbedDiagnostics
- 16:13:16 [nigel]
- rrsagent, draft minutes
- 16:13:16 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel
- 17:23:20 [zcorpan]
- zcorpan has joined #tt
- 18:07:29 [Zakim]
- Zakim has left #tt
- 19:43:29 [zcorpan]
- zcorpan has joined #tt
- 20:01:25 [zcorpan]
- zcorpan has joined #tt
- 21:17:46 [zcorpan]
- zcorpan has joined #tt