W3C home > Mailing lists > Public > public-tt@w3.org > October 2014

{minutes} TTWG Meeting 27/10/2014

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Tue, 28 Oct 2014 00:46:35 +0000
To: TTWG <public-tt@w3.org>
Message-ID: <5941EAB8802D6745A7D363D7B37BD1F75C4E49C9@BGB01XUD1012.national.core.bbc.co.uk>
Thanks all for attending today's face to face meeting. Minutes in HTML format can be found at http://www.w3.org/2014/10/27-tt-minutes.html

We made the following resolutions:

RESOLUTION: We will document the syntax for the external processorProfiles parameter in TTML2.

RESOLUTION: We will host the registry on the wiki (subject to edits as discussed today)

RESOLUTION: We will publish the staged version of WebVTT as a FPWD when the edits to change the occurrences of "Living Standard" to "Draft Community Group Report" have been applied.

The review period for these resolutions ends on 10th November according to our Decision Process.

In text format:


      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

27 Oct 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/10/27-tt-irc


          Cyril, mike, pal, glenn, nigel, courtney, Erik,
          Carlsson, plh, jdsmith, Erik_Carlson

          dsinger, andreas, frans




     * [3]Topics
         1. [4]Introductions
         2. [5]TTML Codecs Registry
         3. [6]MPEG liaison re track header box width and height
         4. [7]WebVTT publication
         5. [8]TTML <--> WebVTT
         6. [9]IMSC 1 WD Review comments
         7. [10]Plan for advancing IMSC 1 to CR
         8. [11]WebVTT FPWD publication
         9. [12]MIME type for TTML2
        10. [13]IMSC 1 WD Review Comments
     * [14]Summary of Action Items

   <trackbot> Date: 27 October 2014

   <scribe> scribeNick: nigel


   All members introduce themselves. Observers: Jangmuk Cho, LG
   electronics, interested in TTML and WebVTT

   nigel: Summarises agenda, offers opportunity for other business

   mike: There's an incoming liaison expected from MPEG

   nigel: adds it to agenda

TTML Codecs Registry


     [15] https://www.w3.org/wiki/TTML/CodecsRegistry

   nigel: We've agreed to host a registry and define a parameter
   ... We need to work out where to define the syntax normatively
   ... And where to note the media registration once we've updated
   it with IANA.

   Cyril: I had two comments on the registry:
   ... 1. The discussion that talks about the first order
   detection of capabilities.
   ... 2. The editorial nature of stpp vs application/ttml+xml

   Mike: We proposed to MPEG that they have their part and W3C has
   its part.

   glenn: That's true - we need to remove the prefix requirement
   on the registry page.

   Cyril: I'd rather delete the sentence "When an entry of this
   registry is used in a codecs parameter..."
   ... Actually the whole paragraph - it's up to MPEG to define
   any codecs parameter, and we can define the
   ... suffix.

   group discusses whether any reference to RFC6381 is needed at

   glenn: I got rid of the RFC6381 references and put the
   combinatorial operators in.

   pal: The AND and OR operators are normative, so it needs to be
   clearly defined.

   cyril: +1

   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.

   cyril: +1

   glenn: When we have it somewhere else we can refer to then we
   can shorten the registry page.

   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.
   ... We should be strict here.

   glenn: My position is that what's in the TTML document is
   what's authoritative, because it stays with the content.

   cyril: Both have to be the same.

   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
   ... and the actual data is where you determine the concrete

   Cyril: I agree, but we need to state it more strongly: it is an
   error in general to have a mismatch.

   glenn: It wouldn't be an error in the document.

   Cyril: I agree - if the two differ then that's an error and the
   value in the document has precedence.

   nigel: There's a lifecycle issue there - a new processor may
   come along that can process older documents.

   glenn: So the outer parameter may reference a new superset

   nigel: exactly.

   glenn: So the rule should be about consistency not identity.

   nigel: The options for where to put it seem to be:
   ... 1. An erratum to TTML1

   2. TTML2

   3. A WG Note

   4. A new Recommendation.

   group seems to think TTML2 may be the best place

   glenn: I'm willing to add it to TTML2 but do not wish to repeat
   the whole registration section.


     [16] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html

   Glenn: We need to tweak section 3.1 in TTML2 "Content

   Cyril: I would rather add an annex in TTML2 called Media Types
   Registration referencing TTML1 plus diffs.

   glenn: That works for me.
   ... I think we can avoid updating the IANA registration
   ... since there's no wording to prohibit adding new parameters.

   Mike: I'm not so sure about that.

   nigel: I don't think we can do that either can we?

   glenn: The TTML2 we should define the new parameter and syntax
   and then reference it in 3.1.

   Cyril: We should put it in a Media Type Registration annex so
   that it's clear. This then uses a reference to TTML1 with
   ... the diffs.

   glenn: I'd like to call the annex something like 'Additional
   parameters for use with TTML media type'.

   Mike: let's check with plh too.

   all agree to point back to TTML1 media registration.

   nigel: It's an open question if we genuinely need to update the
   IANA registration.

   Cyril: In the SVG WG we've made a comment on the charter about
   how documents and versions of documents in TR/
   ... should be handled. We have the same problem here: TTML1
   doesn't talk about TTML2. It points only to the latest
   ... stable version of TTML1.

   pal: They're two different specs - there's no absolute
   guarantee for backward compatibility.

   Cyril: And you're using the same MIME type? SVG 2 is backward
   compatible with SVG 1

   glenn: TTML2 is backward compatible in the sense that a TTML1
   processor would process a TTML2 document, practically speaking.
   ... I defined a new #version feature in TTML2 - if you want to
   author a document for TTML2 and prevent it from being
   ... processed by a TTML1 processor then you could do that by
   using the profile mechanism. If you don't do that then
   ... there's no reason that a TTML1 processor could not process
   it by ignoring things it doesn't understand.
   ... We explicitly stated that the XML namespace for TTML is

   Cyril: THe issue is that the group is giving the signal that
   TTML1SE is the latest version whereas actually everyone is
   ... working on TTML2. If a TTML1 document can be considered a
   TTML2 document...

   pal: Setting aside the media registration, TTML1 and TTML2 are
   different specs, albeit with a common pedigree.

   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
   ... but that's probably not what I want.

   pal: But that's right - the latest stable version now is TTML1.
   Even when TTML2 is a Rec TTML1 will be valid.

   glenn: Think about XML - XML 1 and XML 1.1 are not entirely
   compatible but are still being updated.
   ... In TTML1 we may publish a Third Edition incorporating the

   pal: IMSC 1 is based on TTML1 for example.

   glenn: In the latest version we actually include "ttml1" in the
   URL - TTML2 will be a different URL.

   <glenn> 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 [recorded in

   <trackbot> 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

   mike: There are a number of W3C specs that have this problem.

   Cyril: And that's a problem.

   pal: It's even worse if we don't make it clear that there are
   two different specs.

   Cyril: This is going to stay a problem for anyone searching for

   <pal> [18]http://www.w3.org/XML/Core/

     [18] http://www.w3.org/XML/Core/

   <glenn> [19]http://www.w3.org/TR/CSS/

     [19] http://www.w3.org/TR/CSS/

   pal: The XML WG is explicit about its different publications.

   glenn: The CSS WG explains this with "Levels" and we could do
   that too, with a top level TTML uber-document
   ... as a WG Note to explain the relationship.

   Cyril: I'll volunteer to write a similar note.

   <scribe> ACTION: cyril Draft a WG note explaining the
   differences and relationships between the various versions of
   TTML [recorded in

   <trackbot> 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].

   nigel: That's helpful. Now what do we do about MIME types which
   may be the same for TTML1 and TTML2 documents?

   glenn: That's a good question. In the TTML2 spec I defined a
   new set of baseline profiles, and a new ttp:version attribute.
   ... In of TTML2 we list the 3 profiles from TTML1,
   plus SDP-US, plus 3 new profiles specific to TTML2 including
   newly defined features.
   ... One way to do it is to use different short names in the
   registry for each of these profiles.
   ... The ttp:version attribute is a little orthogonal. It states
   which version of TTML was used in authoring a document
   ... It's required if the document requires support for a
   feature not present in TTML1.
   ... And the Note mentions that the computed value of the
   attribute is used by the construct default processor profile
   ... Omitting the attribute causes the default to be one of the
   TTML1 profiles.

   Cyril: This makes the processorProfiles parameter in the MIME
   type even more important.

   glenn: It's important for any kind of external filtering.

   Cyril: So there's the version attribute, the profile designator
   and externally there's processorProfiles that would use
   ... different short names for TTML2 than for TTML1.

   glenn: Yes. In the new annex we should mention that designating
   externally that something is a profile could result
   ... in a false negative, or a false positive. A false negative
   in the sense that the context may think it can't process, but
   ... within the document it could say 'start with a profile and
   make a feature optional' at a very fine grained level. This
   ... add or remove feature requirements. So if the external
   parameter indicates that the processor can not process, but
   ... the internal parameter says it can, then it would be a
   false negative. The reverse is true. that the document may
   ... an extension feature.

   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.

   glenn: There's also the question of, in the absence of the
   external parameter, what should the semantics be?

   Cyril: it should be less restrictive.

   glenn: It should certainly be no more restrictive than what's
   in the document. The problem is there may be some cases
   ... where there's no way to express the complexity in the
   external parameter.
   ... One of my observations is that people want to simplify the
   profiles mechanism in the external parameter. Is that what
   people are thinking?

   pal: Unless we put something in then people will just define
   their own way of doing it.

   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.

   <pal> pal: doing it == "signal that a document conforms to one
   or more specifications"

   glenn: It's not that bad - you can just parse the head.

   courtney: You still have to parse the whole head.

   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.

   courtney: So there's no goal to efficiently reject files?

   glenn: We just used a similar mechanism to SVG. We assumed that
   the head would be parsed before the body.

   courtney: It defeats the purpose of profiles to allow people to
   pick and choose features.

   pal: If this group doesn't do it then others will.

   nigel: But they probably wouldn't include the feature addition
   and subtraction semantics.

   glenn: But the short registry doesn't define what a document
   conforms to.

   group discusses the topic further (scribe misses details)

   cyril: What does EBU-TT-D say?

   nigel: It permits extensions by default, but wouldn't do
   anything with them. It doesn't use profiles.
   ... Andreas raised the query about how complex it is to
   register a short name - the email discussion seems to indicate
   ... that there's no requirement to create a full profile
   definition document; a short name can be registered with the
   ... details from the spec document in the absence of a full
   profile document.
   ... 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
   ... the complexity of the internal profile mechanism.

   pal: So we're okay to keep the same application/ttml+xml mime
   type and use the processorProfiles parameter to
   ... distinguish between TTML1 and TTML2, and the processors
   within them.

   RESOLUTION: We will document the syntax for the external
   processorProfiles parameter in TTML2.
   ... We will reuse the same media type in TTML2 as in TTML1 but
   recommend using the processorProfiles external parameter to
   differentiate processor requirements.

   Cyril: what about the registry? Where should it go? The Media
   Source Extensions registry is published not on a wiki but as a

   glenn: the usual practice in W3C is to use a wiki page.


     [21] https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/byte-stream-format-registry.html

   Cyril: For MPEG the registry needs to have a stable URL.

   nigel and glenn: We can keep a stable URL with a wiki.

   RESOLUTION: We will host the registry on the wiki (subject to
   edits as discussed today)

   nigel: Opens up MPEG response for those in the room to see.

   Cyril: MPEG accepts the registry proposal from W3C.
   ... MPEG has no comments on IMSC at this time.
   ... 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.
   ... So MPEG drafted corrigenda to 14496-12 and 14496-30.
   ... 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
   ... 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.
   ... 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.
   ... So MPEG fixed this (or it's in the pipeline to fix) that
   the MIME type can be in the MP4 file.

   glenn: Is there a suggestion that there should be an additional
   piece of metadata that includes the short names directly?

   Cyril: I thought that would be redundant with the long profiles

   glenn: It is if you happen to know the details of the registry,
   but otherwise not.
   ... Adding such an attribute would make it more necessary to
   define the syntax in TTML2.

   Cyril: That would be fine, but we've solved it separately in
   MPEG too.

   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
   ... That could limit the ability for distribution mechanisms
   creating MP4 files from old TTML files from generating an up to
   date external processorProfiles parameter.

   glenn: I understand that concern. Early binding could be worse
   than late binding, for document wrapping.

   group discusses the possibilities, concludes that we will not
   propose to put the short codes into TTML documents.

   Additional observer: Tatsuya Hayashi - interested in time
   synchronisation with audio

MPEG liaison re track header box width and height

   nigel: shows on screen the early draft liaison. Describes an
   issue with signalling track header width and height fields.

   glenn: I think I have an action for when no extent is specified
   and there is a related media object.

   Cyril: In MP4 we had the problem that in adaptive streaming
   there may be an MP4 file with no video, just the text track.

   mike: In the external context there's always a related media
   object somewhere, either in the file or in the MPD manifest in

   glenn: We don't limit the scope of how the related media object
   is provided.

   Cyril: 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.
   ... 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.
   ... Each video track can have a different presentation size,
   related to each other using transformation matrices.

   pal: On the same dimensions?

   Cyril: Yes, on the presentation coordinate system.
   ... We had two problems. Firstly, a document may be authored
   independent of resolution, second the aspect ratio may not be
   known, and be important.
   ... The two corrigendums deal with this.
   ... The -12 spec was too prescriptive about visual tracks - it
   turns out that it is track type dependent.
   ... There is a new definition of a reserved 0 0 size value.
   Concerns have been raised.

   mike: Introduces the liaison and supporting documents. They
   will be available to the group in the next few weeks.

   Cyril: This is equally applicable to WebVTT, SVG tracks, HTML
   tracks, any graphical vector graphics based tracks [as well as
   ... Takes us through the proposed changes to 14496-30.

   group discusses track selection behaviour based on aspect

WebVTT publication

   nigel: We have a proposal still to publish WebVTT as a FPWD.
   The edits requested to the staged version were made.


     [22] http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html

   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.

   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.

   Cyril: Anyone wanting to work with WebVTT will always look at
   the editor's draft.

   glenn: I don't mind the process, but I'm not happy with the
   term Living Standard.
   ... It looks like it will set a precedent.

   mike: Use of the term Living Standard needs to be something
   that the W3C expresses a view on.

   Cyril: What if Living Standard were changed to Draft Community
   Group Report?

   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.
   ... Objects to the use of the term Living Standard. Acceptable
   proposals to resolve this are "Editor's Draft" or "Draft
   Community Group Report".

   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)

   <scribe> ACTION: nigel Make request to Philip and Silvia to
   change Living Standard to Editor's Draft. [recorded in

   <trackbot> Created ACTION-345 - Make request to philip and
   silvia to change living standard to editor's draft. [on Nigel
   Megitt - due 2014-11-03].

   nigel: Going from WD to CR for WebVTT?
   ... 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.

TTML <--> WebVTT

   nigel: Current status is that we have a git repo with some but
   not all of the tests we worked on in Geneva.

   courtney: And I don't have a draft document ready.
   ... I've prioritised working on the document ahead of the code.

   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.

   courtney: My goal is to have a version of the document ready by
   the beginning of December, as a fairly complete 1st draft for
   ... I don't know exactly when I will have the software ready.

   nigel: We don't seem to have all the tests from Geneva - is
   there a reason why they can't all be submitted?

   group: no reason

   nigel: Okay, the action to submit them to me remains.
   ... It would make sense to transfer the git repo to courtney at
   some point - no pressure on time.

   courtney: Okay, I can do that.

   nigel: We have no more substantive points to discuss on this so
   let's adjourn for lunch.
   ... We'll reconvene at 1345

IMSC 1 WD Review comments

   pal: LC-2968
   ... 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.
   ... Describes notes and resolution.
   ... LC-2971.
   ... LC-2969.
   ... LC-2970.
   ... LC-2967.

     [24] https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttml-imsc1-20140930/2968?cid=2968

Plan for advancing IMSC 1 to CR

   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.

   pal: What are the licensing expectations for test material?

   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.
   ... 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.
   ... 2. For any other purpose we don't really care.
   ... The second one is the BSD license.
   ... What's the issue?

   mike: The question is what W3C is asking for - which you just

   plh: W3C needs the rights to modify the files and make them
   available to the public under the W3C license.

   group looks at the DECE license requirements

   plh: It doesn't permit modification.

   mike: I'll explore this with DECE to check that they can
   provide test documents that will be usable by W3C for this
   ... 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).

   <plh> http/www.w3.org/2002/09/wbs/1/testgrants2-200409/

   plh: The 'this is closed since 01 October 2013' is a bug -
   ignore it.
   ... The text you're looking for is in section 2 on this page.

   nigel and philippe send DECE a note via Mike.

   nigel: Next up - do we have enough evidence of wide review?

   pal: The member submission itself was based on the work of 80
   members, from both the CE and the content publishing space.
   ... This is a specification that was used in the implementation
   of playback devices. So it already received a significant
   amount of scrutiny.
   ... Since being brought to W3C it has received comments from

   plh: On Sep 24 SMPTE said they have no outstanding comments on
   IMSC 1.

   pal: Earlier today DVB stated that they have reviewed and have
   no comments.
   ... Plus we can point to the members of this group and their
   representation, and that it was reviewed by the a11y group of
   the HTML group.
   ... And we requested comments from a significant number of

   plh: Another group that would be important if the PFWG.
   ... At the end of the day it's a profile not a whole new spec.

   glenn: I think this has wider review than TTML1 did, at least
   bringing in DVB, EBU and DECE.

   plh: My feeling is that you've done enough.

   nigel: Great, then the next point is CR exit criteria.

   nigel takes group through slide pack on CR exit criteria,
   triggering much debate.

   <scribe> ACTION: nigel Scribe notes on CR exit criteria for
   IMSC 1 based on meeting debate [recorded in

   <trackbot> Created ACTION-346 - Scribe notes on cr exit
   criteria for imsc 1 based on meeting debate [on Nigel Megitt -
   due 2014-11-03].

   <plh> [26]http://www.w3.org/TR/2014/CR-html5-20140731/

     [26] http://www.w3.org/TR/2014/CR-html5-20140731/

WebVTT FPWD publication

   plh: Calling it Living Standard will cause a problem. "Draft
   Community Group Report" would be acceptable.

   RESOLUTION: We will publish the staged version of WebVTT as a
   FPWD when the edits to change the occurrences of "Living
   Standard" to "Draft Community Group Report" have been applied.

MIME type for TTML2

   Cyril: summarises morning resolutions

   plh: My understanding is that IANA needs a complete new
   registration to overwrite the previous one.

   glenn: It seems confusing to have two different registrations
   for the same MIME type.

   Cyril: We can link back from the TTML2 section on media
   registration to the TTML1 definition.

   nigel: Mike volunteered to do the re-registration - is that
   okay for it not to be a member of W3C staff?

   plh: Yes, it's fine for me to be out of the loop and not a
   bottleneck - I just have to tell the IESG that it's okay

IMSC 1 WD Review Comments

   pal: the other comments are from Andreas Tai

   nigel: Let's go through them. Actually it's too hard to put
   them all in the issue tracker - we did 5.2 but let's just talk
   through the others.

   pal: 3. Conformance - subtitle document not being defined. I
   can just take that on - it should probably say 'document
   instance' like TTML does.
   ... 4.1 - I'm happy to add the proposal.
   ... 5.7.3 - I agree it would be useful to show all the
   combinations of the parameter and the attribute for
   ... 5.7.4 - I should be able to implement the proposal and the
   ... 5.10 - this is a good suggestion a priori
   ... 6.3 - This is a good point - I should link to 9.3.1 in
   ... 8.2 - Andreas is suggesting that we use the terms
   presentation processor and transformation processor now that we
   have them.
   ... I have to think hard about this. I think the intent of the
   text is the same as the note on overflow, where we talk about
   authoring of the documents.
   ... Section 8.2 doesn't necessarily say that the presentation
   processor shall lay out text in this way. I'm pretty sure it
   refers to how its authored.

   glenn: If that were the intent I would have written it
   differently, e.g. "for the purpose of avoiding overflow, the
   author shall or should..." etc

   nigel: Since this is in section 8 does it only apply to layout
   for the purpose of calculating the HRM values?

   pal: 8.1 is Performance, 8.2 is Reference Fonts. Since the HRM
   section is referenced as 'documents shall conform to these
   constraints' I think it's about authoring not presentation.
   ... If this is the case then there isn't a strict constraint on
   processors at all. I'll study this and come up with a proposal
   for us to consider in addressing Andreas's comments.
   ... Annex B Forced Content - we're going to put some code
   snippets in there.
   ... 5.10 #length-cell - I have to think about this. What's the
   reason for needing cell metrics in documents for linePadding?

   nigel: It makes it easier to make the padding distance a
   fraction of the font size, which is a typical use case.

   pal: 5.2 The current text was direct input from EBU so we
   shouldn't modify it lightly. Perhaps if EBU comes back and says
   something different this would be easier to resolve.

   nigel: We've completed our agenda for today, so adjourning.
   Thanks all. We restart tomorrow at 0830.

Summary of Action Items

   [NEW] ACTION: cyril Draft a WG note explaining the differences
   and relationships between the various versions of TTML
   [recorded in
   [NEW] 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 [recorded in
   [NEW] ACTION: nigel Make request to Philip and Silvia to change
   Living Standard to Editor's Draft. [recorded in
   [NEW] ACTION: nigel Scribe notes on CR exit criteria for IMSC 1
   based on meeting debate [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [31]scribe.perl version
    1.138 ([32]CVS log)
    $Date: 2014-10-28 00:41:29 $

     [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [32] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 28 October 2014 00:47:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:42 UTC