15:35:16 RRSAgent has joined #tt 15:35:17 logging to http://www.w3.org/2014/10/27-tt-irc 15:35:18 RRSAgent, make logs public 15:35:18 Zakim has joined #tt 15:35:20 Zakim, this will be TTML 15:35:21 Meeting: Timed Text Working Group Teleconference 15:35:21 Date: 27 October 2014 15:35:21 I do not see a conference matching that name scheduled within the next hour, trackbot 15:36:02 Present: Cyril, mike, pal, glenn, nigel 15:36:05 chair: nigel 15:43:44 Present+ courtney 15:51:34 scribeNick: nigel 15:53:03 Topic: Introductions 15:53:25 nigel: All members introduce themselves. Observers: Jangmuk Cho, LG electronics, interested in TTML and WebVTT 15:53:32 s/nigel: / 15:57:08 nigel: Summarises agenda, offers opportunity for other business 15:57:14 mike: There's an incoming liaison expected from MPEG 15:57:21 nigel: adds it to agenda 15:57:34 Topic: TTML Codecs Registry 15:59:44 glenn has joined #tt 15:59:46 https://www.w3.org/wiki/TTML/CodecsRegistry 16:00:16 nigel: We've agreed to host a registry and define a parameter 16:00:30 ... We need to work out where to define the syntax normatively 16:00:42 ... And where to note the media registration once we've updated it with IANA. 16:01:03 Cyril: I had two comments on the registry: 16:01:16 ... 1. The discussion that talks about the first order detection of capabilities. 16:01:34 ... 2. The editorial nature of stpp vs application/ttml+xml 16:02:47 Mike: We proposed to MPEG that they have their part and W3C has its part. 16:03:35 glenn: That's true - we need to remove the prefix requirement on the registry page. 16:03:54 Cyril: I'd rather delete the sentence "When an entry of this registry is used in a codecs parameter..." 16:04:46 ... Actually the whole paragraph - it's up to MPEG to define any codecs parameter, and we can define the 16:04:51 ... suffix. 16:08:38 group discusses whether any reference to RFC6381 is needed at all 16:10:11 glenn: I got rid of the RFC6381 references and put the combinatorial operators in. 16:10:29 plh has joined #tt 16:11:44 pal: The AND and OR operators are normative, so it needs to be clearly defined. 16:11:54 cyril: +1 16:12:14 glenn: First we have to define where we're going to specify the normative definition of this new parameter - it shouldn't end up in the registry. 16:12:19 cyril: +1 16:12:37 glenn: When we have it somewhere else we can refer to then we can shorten the registry page. 16:13:34 Cyril: Can we also discuss the 1st order aspect, where it says that the processor profile is guidance only and may not always be correct. 16:13:38 ... We should be strict here. 16:13:57 glenn: My position is that what's in the TTML document is what's authoritative, because it stays with the content. 16:14:06 cyril: Both have to be the same. 16:14:28 glenn: Even if you say they have to be the same, it's possible for them to diverge. Elsewhere, type identifiers are always documented as hints 16:14:37 ... and the actual data is where you determine the concrete type. 16:14:53 Cyril: I agree, but we need to state it more strongly: it is an error in general to have a mismatch. 16:14:59 glenn: It wouldn't be an error in the document. 16:15:14 Cyril: I agree - if the two differ then that's an error and the value in the document has precedence. 16:16:25 nigel: There's a lifecycle issue there - a new processor may come along that can process older documents. 16:16:39 glenn: So the outer parameter may reference a new superset profile? 16:16:47 nigel: exactly. 16:16:56 glenn: So the rule should be about consistency not identity. 16:18:00 nigel: The options for where to put it seem to be: 16:18:06 ... 1. An erratum to TTML1 16:18:09 2. TTML2 16:18:12 3. A WG Note 16:18:16 4. A new Recommendation. 16:19:14 group seems to think TTML2 may be the best place 16:20:37 glenn: I'm willing to add it to TTML2 but do not wish to repeat the whole registration section. 16:21:14 courtney has joined #tt 16:22:02 https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html 16:23:16 Glenn: We need to tweak section 3.1 in TTML2 "Content Conformance" 16:23:48 Cyril: I would rather add an annex in TTML2 called Media Types Registration referencing TTML1 plus diffs. 16:23:52 glenn: That works for me. 16:24:39 glenn: I think we can avoid updating the IANA registration 16:24:51 ... since there's no wording to prohibit adding new parameters. 16:25:02 Mike: I'm not so sure about that. 16:25:10 nigel: I don't think we can do that either can we? 16:26:28 Cyril: The TTML2 we should define the new parameter and syntax and then reference it in 3.1. 16:26:37 s/Cyril/glenn 16:26:54 jdsmith_ has joined #tt 16:27:09 Cyril: We should put it in a Media Type Registration annex so that it's clear. This then uses a reference to TTML1 with 16:27:12 ... the diffs. 16:27:33 glenn: I'd like to call the annex something like 'Additional parameters for use with TTML media type'. 16:27:45 Mike: let's check with plh too. 16:27:59 all agree to point back to TTML1 media registration. 16:28:20 nigel: It's an open question if we genuinely need to update the IANA registration. 16:28:46 Cyril: In the SVG WG we've made a comment on the charter about how documents and versions of documents in TR/ 16:29:05 ... should be handled. We have the same problem here: TTML1 doesn't talk about TTML2. It points only to the latest 16:29:10 ... stable version of TTML1. 16:29:25 pal: They're two different specs - there's no absolute guarantee for backward compatibility. 16:29:42 Cyril: And you're using the same MIME type? SVG 2 is backward compatible with SVG 1 16:30:20 glenn: TTML2 is backward compatible in the sense that a TTML1 processor would process a TTML2 document, practically speaking. 16:30:46 ... I defined a new #version feature in TTML2 - if you want to author a document for TTML2 and prevent it from being 16:31:04 ... processed by a TTML1 processor then you could do that by using the profile mechanism. If you don't do that then 16:31:23 ... there's no reason that a TTML1 processor could not process it by ignoring things it doesn't understand. 16:31:35 ... We explicitly stated that the XML namespace for TTML is mutable. 16:31:53 Cyril: THe issue is that the group is giving the signal that TTML1SE is the latest version whereas actually everyone is 16:32:03 ... working on TTML2. If a TTML1 document can be considered a TTML2 document... 16:32:28 pal: Setting aside the media registration, TTML1 and TTML2 are different specs, albeit with a common pedigree. 16:32:53 Cyril: If I search for TTML now, I'll find many documents and if I hit the TTML1 document it will look like the latest version 16:32:58 ... but that's probably not what I want. 16:33:54 pal: But that's right - the latest stable version now is TTML1. Even when TTML2 is a Rec TTML1 will be valid. 16:34:25 glenn: Think about XML - XML 1 and XML 1.1 are not entirely compatible but are still being updated. 16:34:43 ... In TTML1 we may publish a Third Edition incorporating the errata. 16:34:50 pal: IMSC 1 is based on TTML1 for example. 16:35:11 glenn: In the latest version we actually include "ttml1" in the URL - TTML2 will be a different URL. 16:35:46 action glenn to update point (1) of section 3.1 in ttml2 to refer to a new annex that defines new processorProfiles MIME type parameter 16:35:47 Created ACTION-343 - Update point (1) of section 3.1 in ttml2 to refer to a new annex that defines new processorprofiles mime type parameter [on Glenn Adams - due 2014-11-03]. 16:36:22 mike: There are a number of W3C specs that have this problem. 16:36:29 Cyril: And that's a problem. 16:36:45 pal: It's even worse if we don't make it clear that there are two different specs. 16:37:53 pal has joined #tt 16:37:55 Cyril: This is going to stay a problem for anyone searching for TTML 16:37:57 http://www.w3.org/XML/Core/ 16:38:26 http://www.w3.org/TR/CSS/ 16:38:29 pal: The XML WG is explicit about its different publications. 16:39:06 glenn: The CSS WG explains this with "Levels" and we could do that too, with a top level TTML uber-document 16:39:18 ... as a WG Note to explain the relationship. 16:39:34 Cyril: I'll volunteer to write a similar note. 16:40:00 Action: cyril Draft a WG note explaining the differences and relationships between the various versions of TTML 16:40:01 Created ACTION-344 - Draft a wg note explaining the differences and relationships between the various versions of ttml [on Cyril Concolato - due 2014-11-03]. 16:40:14 s/action glenn/Action: glenn 16:40:49 nigel: That's helpful. Now what do we do about MIME types which may be the same for TTML1 and TTML2 documents? 16:41:09 glenn: That's a good question. In the TTML2 spec I defined a new set of baseline profiles, and a new ttp:version attribute. 16:42:20 ... In ยง5.2.3.1 of TTML2 we list the 3 profiles from TTML1, plus SDP-US, plus 3 new profiles specific to TTML2 including newly defined features. 16:42:43 ... One way to do it is to use different short names in the registry for each of these profiles. 16:43:21 ... The ttp:version attribute is a little orthogonal. It states which version of TTML was used in authoring a document instance. 16:43:37 ... It's required if the document requires support for a feature not present in TTML1. 16:44:10 ... In the Note mentions that the computed value of the attribute is used by the construct default processor profile procedure. 16:44:19 s/In/And 16:44:46 ... Omitting the attribute causes the default to be one of the TTML1 profiles. 16:45:04 Cyril: This makes the processorProfiles parameter in the MIME type even more important. 16:45:11 glenn: It's important for any kind of external filtering. 16:45:51 Cyril: So there's the version attribute, the profile designator and externally there's processorProfiles that would use 16:45:57 ... different short names for TTML2 than for TTML1. 16:46:16 glenn: Yes. In the new annex we should mention that designating externally that something is a profile could result 16:46:40 ... in a false negative, or a false positive. A false negative in the sense that the context may think it can't process, but 16:47:21 ... within the document it could say 'start with a profile and make a feature optional' at a very fine grained level. This could 16:47:45 ... add or remove feature requirements. So if the external parameter indicates that the processor can not process, but 16:48:04 ... the internal parameter says it can, then it would be a false negative. The reverse is true. that the document may require 16:49:12 ... an extension feature. 16:51:32 nigel: But you could just locally define a new profile short name for an extension, and put that in the external processorProfiles parameter with the AND operator. 16:52:45 glenn: There's also the question of, in the absence of the external parameter, what should the semantics be? 16:52:52 Cyril: it should be less restrictive. 16:53:11 glenn: It should certainly be no more restrictive than what's in the document. The problem is there may be some cases 16:53:29 ... where there's no way to express the complexity in the external parameter. 16:53:59 glenn: One of my observations is that people want to simplify the profiles mechanism in the external parameter. Is that what people are thinking? 16:54:22 pal: Unless we put something in then people will just define their own way of doing it. 16:55:10 courtney: From a parser-writing perspective there's no efficient way to look at the supported profile requirements. You have to parse the whole thing. 16:55:10 pal: doing it == "signal that a document conforms to one or more specifications" 16:55:18 glenn: It's not that bad - you can just parse the head. 16:55:27 courtney: You still have to parse the whole head. 16:56:04 glenn: It's much better than SVG 1.1 which mandates full parsing to determine if it is a well formed XML document, even down to the last closing tag. 16:56:17 courtney: So there's no goal to efficiently reject files? 16:56:40 glenn: We just used a similar mechanism to SVG. We assumed that the head would be parsed before the body. 16:57:13 courtney: It defeats the purpose of profiles to allow people to pick and choose features. 16:57:23 pal: If this group doesn't do it then others will. 16:57:41 nigel: But they probably wouldn't include the feature addition and subtraction semantics. 16:57:56 glenn: But the short registry doesn't define what a document conforms to. 17:01:44 group discusses the topic further (scribe misses details) 17:01:50 cyril: What does EBU-TT-D say? 17:02:17 nigel: It permits extensions by default, but wouldn't do anything with them. It doesn't use profiles. 17:02:33 ... Andreas raised the query about how complex it is to register a short name - the email discussion seems to indicate 17:02:55 ... that there's no requirement to create a full profile definition document; a short name can be registered with the 17:03:16 ... details from the spec document in the absence of a full profile document. 17:03:53 nigel: By the way, as I think Dave mentioned a while back, you can also just define a new short name if you don't want to hit 17:04:00 ... the complexity of the internal profile mechanism. 17:04:25 pal: So we're okay to keep the same application/ttml+xml mime type and use the processorProfiles parameter to 17:04:37 ... distinguish between TTML1 and TTML2, and the processors within them. 17:05:53 Resolution: We will document the syntax for the external processorProfiles parameter in TTML2. 17:06:55 Resolution: We will reuse the same media type in TTML2 as in TTML1 but recommend using the processorProfiles external parameter to differentiate processor requirements. 17:08:25 Cyril: what about the registry? Where should it go? The Media Source Extensions registry is published not on a wiki but as a document. 17:08:32 glenn: the usual practice in W3C is to use a wiki page. 17:08:35 https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/byte-stream-format-registry.html 17:09:30 Cyril: For MPEG the registry needs to have a stable URL. 17:09:39 nigel and glenn: We can keep a stable URL with a wiki. 17:10:04 Resolution: We will host the registry on the wiki (subject to edits as discussed today) 17:10:37 plh has joined #tt 17:11:18 courtney has joined #tt 17:11:33 nigel: Opens up MPEG response for those in the room to see. 17:12:10 Mike: MPEG accepts the registry proposal from W3C. 17:12:20 ... MPEG has no comments on IMSC at this time. 17:13:04 ... There was also discussion of track header width and height in the ISO BMFF. In many cases it's intentionally unknown what the TTML extent is. 17:13:45 ... So MPEG drafted corrigenda to 14496-12 and 14496-30. 17:14:15 Cyril: in the MPEG discussion also, from an MPEG perspective you can usually extract the codecs value from the bitstream. For TTML that isn't exactly the case, because 17:14:34 ... you have to produce the short name from a profile designator in the document, so you need extra knowledge to convert the long name into the short name. 17:15:03 ... So MPEG is considering adding a new box just to contain the MIME type to remove the need for the extra knowledge. You'd be able to put the MIME type of a TTML document in a TTML track. 17:16:23 ... So MPEG fixed this (or it's in the pipeline to fix) that the MIME type can be in the MP4 file. 17:16:46 glenn: Is there a suggestion that there should be an additional piece of metadata that includes the short names directly? 17:16:56 Cyril: I thought that would be redundant with the long profiles designator. 17:17:34 glenn: It is if you happen to know the details of the registry, but otherwise not. 17:17:52 ... Adding such an attribute would make it more necessary to define the syntax in TTML2. 17:19:29 Cyril: That would be fine, but we've solved it separately in MPEG too. 17:26:31 nigel: I'd be concerned about putting the short codes in the TTML because that would encourage folk to extract the value from the TTML and put it into the (proposed) MP4 MIME attribute. 17:27:13 ... That could limit the ability for distribution mechanisms creating MP4 files from old TTML files from generating an up to date external processorProfiles parameter. 17:34:43 glenn: I understand that concern. Early binding could be worse than late binding, for document wrapping. 17:35:25 group discusses the possibilities, concludes that we will not propose to put the short codes into TTML documents. 17:35:30 rrsagent, generate minutes 17:35:30 I have made the request to generate http://www.w3.org/2014/10/27-tt-minutes.html nigel 17:44:34 Zakim has left #tt 17:49:34 courtney has joined #tt 17:56:39 pal has joined #tt 18:04:31 Additional observer: Tatsuya Hayashi - interested in time synchronisation with audio 18:05:05 Topic: MPEG liaison re track header box width and height 18:06:16 nigel: shows on screen the early draft liaison. Describes an issue with signalling track header width and height fields. 18:06:35 glenn: I think I have an action for when no extent is specified and there is a related media object. 18:06:56 Cyril: In MP4 we had the problem that in adaptive streaming there may be an MP4 file with no video, just the text track. 18:07:16 mike: In the external context there's always a related media object somewhere, either in the file or in the MPD manifest in DASH. 18:07:26 glenn: We don't limit the scope of how the related media object is provided. 18:08:02 mike: We added a bit that says that the width and height can be the aspect ratio instead of the actual width and height, and can be zero if you don't know. 18:08:53 Cyril: From an MPEG perspective a video can have encoded pixel dimensions, or output pixel dimensions. In the end there's a presentation size expressed in pixels. 18:09:08 ... Each video track can have a different presentation size, related to each other using transformation matrices. 18:09:16 pal: On the same dimensions? 18:09:31 Cyril: Yes, on the presentation coordinate system. 18:09:58 mike: We had two problems. Firstly, a document may be authored independent of resolution, second the aspect ratio may not be known, and be important. 18:10:04 ... The two corrigendums deal with this. 18:10:25 ... The -12 spec was too prescriptive about visual tracks - it turns out that it is track type dependent. 18:11:15 ... There is a new definition of a reserved 0 0 size value. Concerns have been raised. 18:11:47 mike: Introduces the liaison and supporting documents. They will be available to the group in the next few weeks. 18:12:20 Cyril: This is equally applicable to WebVTT, SVG tracks, HTML tracks, any graphical vector graphics based tracks [as well as TTML] 18:16:25 Cyril: Takes us through the proposed changes to 14496-30. 18:29:08 group discusses track selection behaviour based on aspect ratio. 18:35:48 Topic: WebVTT publication 18:36:47 nigel: We have a proposal still to publish WebVTT as a FPWD. The edits requested to the staged version were made. 18:37:19 http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html 18:38:20 Resolution: We will publish http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html as the FPWD of WebVTT 18:40:51 courtney has joined #tt 18:55:28 atai has joined #tt 18:58:53 group discusses the use of the term Living Standard and how forks are managed, bringing in CG changes into the WG document, and FSA requirements for doing so. 19:01:39 and that it's the editors' responsibility to maintain any differences between CG and WG versions, and update the WG version each time a new version is to be published by WG. 19:03:29 jdsmith_ has joined #tt 19:03:53 Cyril: Anyone wanting to work with WebVTT will always look at the editor's draft. 19:04:22 glenn: I don't mind the process, but I'm not happy with the term Living Standard. 19:04:55 ... It looks like it will set a precedent. 19:05:35 mike: Use of the term Living Standard needs to be something that the W3C expresses a view on. 19:06:25 Cyril: What if Living Standard were changed to Draft Community Group Report? 19:07:23 timeless has joined #tt 19:07:24 glenn: I could live with that. Editor's Draft may be even better, to make it clear that this is within the normal WG process for a Rec track document. 19:07:27 I'm logging. I don't understand 'this meeting spans midnight <- if you want a single log for the two days', timeless. Try /msg RRSAgent help 19:08:08 RRSAgent, this meeting spans midnight 19:08:34 timeless has left #tt 19:09:18 courtney has joined #tt 19:09:21 s|Resolution: We will publish http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html as the FPWD of WebVTT| 19:10:17 glenn: Objects to the use of the term Living Standard. Acceptable proposals to resolve this are "Editor's Draft" or "Draft Community Group Report". 19:14:44 pal: How will reviewers of future WG versions of the document be able to trace back why any particular change was made? (noting that this is only possible on the CG version now) 19:15:25 Action: nigel Make request to Philip and Silvia to change Living Standard to Editor's Draft. 19:15:26 Created ACTION-345 - Make request to philip and silvia to change living standard to editor's draft. [on Nigel Megitt - due 2014-11-03]. 19:17:02 nigel: Going from WD to CR for WebVTT? 19:21:37 nigel: Dave planned to send notes out essentially to the same set of recipients as we sent to for IMSC 1, as well as socializing at TPAC. 19:25:59 Topic: TTML <--> WebVTT 19:26:53 nigel: Current status is that we have a git rep with some but not all of the tests we worked on in Geneva. 19:27:00 courtney: And I don't have a draft document ready. 19:27:18 courtney: I've prioritised working on the document ahead of the code. 19:27:41 pal: What's the timescale for this? It would be a great addition to the IMSC 1 test suite, if that software could be part of it. 19:28:01 courtney: My goal is to have a version of the document ready by the beginning of December, as a fairly complete 1st draft for comments. 19:28:13 ... I don't know exactly when I will have the software ready. 19:30:00 nigel: We don't seem to have all the tests from Geneva - is there a reason why they can't all be submitted? 19:30:04 group: no reason 19:30:11 nigel: Okay, the action to submit them to me remains. 19:31:22 nigel: It would make sense to transfer the git repo to courtney at some point - no pressure on time. 19:31:26 courtney: Okay, I can do that. 19:32:54 nigel: We have no more substantive points to discuss on this so let's adjourn for lunch. 19:35:03 nigel: We'll reconvene at 1345 19:37:31 rrsagent, draft minutes 19:37:31 I have made the request to generate http://www.w3.org/2014/10/27-tt-minutes.html nigel 20:39:35 jdsmith_ has joined #tt 20:52:32 pal has joined #tt 21:00:05 Cyril has joined #tt 21:03:18 glenn has joined #tt 21:06:09 Present+ Erik Carlsson 21:07:22 glenn_ has joined #tt 21:09:34 Topic: IMSC 1 WD Review comments 21:09:48 pal: LC-2968 https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttml-imsc1-20140930/2968?cid=2968 21:11:05 pal: This is a version of implied inline regions, which isn't supported in TTML1. There's an alternative solution available, so I propose to do nothing. 21:17:28 courtney has joined #tt 21:22:14 pal: Describes notes and resolution. 21:22:31 pal: LC-2971. 21:26:13 pal: LC-2969. 21:38:27 pal: LC-2970. 21:42:48 pal: LC-2967. 21:46:36 jdsmith_ has left #tt 21:47:17 jdsmith_ has joined #tt 21:53:58 plh has joined #tt 21:54:52 Present+ plh 21:56:36 Topic: Plan for advancing IMSC 1 to CR 21:58:19 nigel: We have to think about what exit criteria to write into the CR; if we have enough evidence of wide review; what the license expectations are for test material. 21:59:04 pal: What are the licensing expectations for test material? 21:59:33 plh: The goal here is, if the group is using a test suite to demonstrate suitability for advancement, the Director will want to make that test suite available to all. 22:00:01 ... For that what we've done so far is to provide tests under dual license: 1. If you're going to use those tests for conformance claims, you may not modify them. 22:00:08 ... 2. For any other purpose we don't really care. 22:00:22 ... The second one is the BSD license. 22:00:38 ... What's the issue? 22:00:47 mike: The question is what W3C is asking for - which you just answered. 22:01:16 plh: W3C needs the rights to modify the files and make them available to the public under the W3C license. 22:03:30 group looks at the DECE license requirements 22:03:36 plh: It doesn't permit modification. 22:04:32 mike: I'll explore this with DECE to check that they can provide test documents that will be usable by W3C for this purpose. 22:06:28 Cyril has joined #tt 22:07:17 mike: It would be useful if nigel or plh could respond to DECE's email asking if the example files can be issued under the standard W3C license (with the text of that license). 22:07:47 http/www.w3.org/2002/09/wbs/1/testgrants2-200409/ 22:09:01 plh: The 'this is closed since 01 October 2013' is a bug - ignore it. 22:09:33 plh: The text you're looking for is in section 2 on this page. 22:16:34 nigel and philippe send DECE a note via Mike. 22:18:21 nigel: Next up - do we have enough evidence of wide review? 22:19:24 pal: The member submission itself was based on the work of 80 members, from both the CE and the content publishing space. 22:19:35