15:00:01 RRSAgent has joined #tt 15:00:01 logging to http://www.w3.org/2016/01/07-tt-irc 15:00:03 RRSAgent, make logs public 15:00:03 Zakim has joined #tt 15:00:05 Zakim, this will be TTML 15:00:05 I do not see a conference matching that name scheduled within the next hour, trackbot 15:00:06 Meeting: Timed Text Working Group Teleconference 15:00:06 Date: 07 January 2016 15:00:59 Present: nigel 15:01:01 chair: nigel 15:01:03 scribe: nigel 15:01:15 glenn has joined #tt 15:01:45 Present+ glenn 15:02:40 Regrets: tmichel 15:03:25 Topic: This Meeting 15:04:57 atai2 has joined #tt 15:04:57 nigel: Next week David Ronca from Netflix has agreed to present what he couldn't at Sapporo, 15:05:07 ... so I'd like to propose a 2 hour meeting so we can do that and normal business. 15:05:14 ... i.e. on 14th Jan 15:08:12 nigel: For today I propose we look at Actions, IMSC CR3 and issue #111 and TTML2 Editorial Actions. 15:08:20 ... Also as AOB, more on the Emmy award. 15:08:25 ... Any other AOB? 15:08:42 group: no AOB 15:08:55 Topic: Action Items 15:09:00 action-451? 15:09:00 action-451 -- Thierry Michel to Investigate if we are required to move to the 2015 process -- due 2015-12-03 -- PENDINGREVIEW 15:09:00 http://www.w3.org/AudioVideo/TT/tracker/actions/451 15:09:31 nigel: The objection deadline passed on the call for consensus so we have moved to 2015 process. 15:09:35 close action-451 15:09:35 Closed action-451. 15:11:56 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: 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 atai2: Okay, I'll update them. 15:13:59 nigel: Thanks! 15:14:54 Topic: IMSC CR3 etc 15:15:29 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 https://github.com/w3c/imsc/issues/111 15:16:03 mike has joined #tt 15:16:26 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 pal: One way is to give control to Glenn on Webex to review/edit the solution live? 15:19:40 nigel: Just checking everyone can see a shared screen? 15:19:46 group: No objections. 15:20:53 glenn: [shares screen showing proposal text] 15:21:54 glenn: The main objection was that a processor that can work with both profiles simultaneously needs to 15:22:21 ... make a decision on what profile to apply. 15:22:31 q+ mdolan to ask about premises 15:23:05 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 ... 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 ... 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 ... 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 ack mdolan 15:24:11 mdolan, you wanted to ask about premises 15:24:33 mike: An observation: in the known specification and implementations of the predecessor and IMSC 1 the decoders all support both 15:24:58 ... 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 ... 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 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 ... 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 ... 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 ... default scenario here. 15:26:40 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 ... so treating them like the TTML 1 profiles where that processing can be done this is different. 15:27:18 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 ... 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 ... 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 ... presentation process. That can be provided externally by the document interchange process, using sniffing or envelope or context, or 15:28:31 ... 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 ... default normatively. In TTML1 it is the DFXP transformation profile. TTML2 has a more complex algorithm using the version parameter 15:29:13 ... 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 ... Both cases define a fallback default. 15:29:57 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 ... should be possible to define a fallback default like TTML1. 15:30:15 mike: In TTML1 the fallback is trivial - it's full. 15:30:23 glenn: That's not the default - it's transformation. 15:30:35 mike: It's easy because there are no extensions and all profiles are strict subsets. 15:30:56 q+ to ask why a processor needs to make this decision 15:31:25 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 glenn: TTML1 does support extensions so I don't see how IMSC does something different in this regard. The defaulting algorithm 15:32:04 ... 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 ... 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 ... and doesn't provide guidance as to making the decision. 15:33:05 pal: Do you agree that if the image and text profiles were in two specifications then that statement would not apply? 15:33:29 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 pal: I think it is relevant because it's an artefact of the profiles being in the same specification. 15:34:52 ack nigel 15:34:52 nigel, you wanted to ask why a processor needs to make this decision 15:35:14 nigel: Why would you want to do "constraint processing" here given that a processor that can process documents in either profile 15:35:45 ... must logically support the union of features needed to process all features, so why would you need to make the decision? 15:36:05 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 ... 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 ... 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 ... profiles, such as the use of different metrics, and there are per profile constraints defined in §7 and §8. 15:37:15 ... You need to know which rules apply. 15:39:06 nigel: I'm confused still - what behavioural differences would arise if a non-conformant document were processed? 15:39:24 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 ... 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 ... that contains no indication that it is an image profile document. 15:41:30 mike: I'm still not sure I agree with the premise but I'd like to see what you're proposing. 15:41:36 glenn: Let me take you through it. 15:42:09 glenn: [add terminology for single profile processor and multiple profile processor] 15:42:39 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 glenn: Right. 15:42:46 pal: And nothing else? 15:43:09 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 ... 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 ... could be specified elsewhere if we wanted to. 15:44:59 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 glenn: I'll get there. 15:45:43 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 ... proposal without any change in it. Where it says [profile specification] that's the same text as agreed in Sapporo. 15:46:32 ... Then the meat of the proposal under the [profile defaulting] section describes what a single profile processor and multiple profile processor 15:46:35 ... should do. 15:47:05 ... [single] - if profile designator doesn't match processor profile then document processing may be aborted 15:47:34 ... [multiple] - too complex rules to summarise in minutes 15:48:55 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 ... 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 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 ... 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 ... 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 ... to process as a text profile. 15:50:55 mike: What does "tentatively" mean? Does it imply a SHOULD? 15:51:15 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 ... An implementation could choose the image profile - that wouldn't follow the recommendation but would be permitted. 15:51:37 s/term/term SHOULD 15:52:09 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 +q 15:52:22 ... When it is processing it is working on a guess. 15:52:30 ack atai2 15:52:36 ack atai 15:53:03 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 ... choice by using text profile but you have no fact to base the decision on. 15:53:33 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 ... 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 ... apply is to ensure there is some indication of profile, but the intent of this language is to encourage it. 15:55:18 nigel: I can't see behavioural differences for processors based on the profile - what practical difference does this make? 15:55:51 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 ... 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 ... 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 ... makes it hard to interoperably test content in my estimation. The processor needs an indication of what to do. 15:57:30 mike: I agree with Andreas, a recommendation saying that a recommendation or strong encouragement to use profile is helpful, and further, 15:57:56 ... 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 ... this. 15:58:21 glenn: A strong recommendation to mark or signal externally the profile would be fine. I could add that. 15:59:07 ... On discovering a profile incompatibility switching profile - is that what you meant? 15:59:31 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 ... doesn't fit the profile would be better. 16:00:03 glenn: If I were to change the note about potentially aborting would that help? 16:00:15 mike: Yes, where "try the other profile" is the preferred option. 16:01:13 nigel: We're out of time - I don't think we've handled the SDP-US or SMPTE-TT issues. 16:01:30 glenn: I'll work on this in the meantime and we could maybe deal with that next time? 16:02:01 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 ... explicit that it supports only those two profiles, e.g. an 'exclusive multi-profile processor' or something similar. 16:04:33 nigel: Summarising, we need to review a revised version of this and discuss again next week. 16:04:48 glenn: I will post the proposal as a message to the public reflector. 16:05:18 nigel: Thanks all, I'll close the call now [adjourns meeting] 16:05:34 rrsagent, draft minutes 16:05:34 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 16:06:43 Present+ andreas, mike 16:06:50 Present+ pierre 16:06:56 rrsagent, draft minutes 16:06:56 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 16:07:36 s/about premises/about the premise 16:07:37 rrsagent, draft minutes 16:07:37 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 16:11:01 s/+q/q+ 16:11:03 rrsagent, draft minutes 16:11:03 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 16:12:08 s/recommendation saying that a recommendation/recommendation/ 16:12:13 rrsagent, draft minutes 16:12:13 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 16:13:14 ScribeOptions: -final -noEmbedDiagnostics 16:13:16 rrsagent, draft minutes 16:13:16 I have made the request to generate http://www.w3.org/2016/01/07-tt-minutes.html nigel 17:23:20 zcorpan has joined #tt 18:07:29 Zakim has left #tt 19:43:29 zcorpan has joined #tt 20:01:25 zcorpan has joined #tt 21:17:46 zcorpan has joined #tt