RE: {minutes} TTWG Meeting 27/10/2014

Hi Nigel,

Thank you for for prompt reply! Ah.. I see. Now I understand the conformant processors.

Rgs,
-- Yoshiharu

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Tuesday, October 28, 2014 10:38 AM
To: Dewa, Yoshiharu (OSAKI); TTWG
Subject: RE: {minutes} TTWG Meeting 27/10/2014

Hi Yoshiharu,

this simply means that conformant processors must be able to transform both textOutline attributes that include a blur radius specification and those that do not include a blur radius specification, i.e. both possibilities that may be encountered in documents. It does not require that a single textOutline attribute must both include and not include a blur radius at the same time.

kind regards,

Nigel

--

Nigel Megitt
Lead Technologist, BBC Technology, Distribution & Archives
Telephone: +44 (0)208 0082360
Telephone (Lync): +44 (0)3030807996
Lync internal: 0807996
BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP

________________________________
From: Dewa, Yoshiharu (OSAKI) [Yoshiharu.Dewa@jp.sony.com]
Sent: 28 October 2014 01:02
To: Nigel Megitt; TTWG
Subject: RE: {minutes} TTWG Meeting 27/10/2014
Hi TTWG folks,

I'm new in this group, but I have one question about TTML2 full profile. I'm happy if someone have an answer.

When I saw F.1 TTML2 Full Profile, there are following definition.

    <feature value="required">#textOutline-blurred</feature>
    <feature value="required">#textOutline-unblurred</feature>

There two features are contradictory. One is "is capable of transforming values of the tts:textOutline attribute that includes a blur radius specification." and the other is "is capable of transforming values of the tts:textOutline attribute that does not include a blur radius specification."

What is the situation that these both features are "required" at same time?

I found these lines fully derived from TTML1 so perhaps I'm missing something.

Rgs,
-- Yoshiharu

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Tuesday, October 28, 2014 9:47 AM
To: TTWG
Subject: {minutes} TTWG Meeting 27/10/2014

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]W3C



      [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



Attendees



   Present

          Cyril, mike, pal, glenn, nigel, courtney, Erik,

          Carlsson, plh, jdsmith, Erik_Carlson



   Regrets

          dsinger, andreas, frans



   Chair

          nigel



   Scribe

          nigel



Contents



     * [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



Introductions



   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



     [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

   all



   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

   type.



   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

   profile?



   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/ttm

   l2.html



     [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

   Conformance"



   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

   mutable.



   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

   version

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

   errata.



   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

   [17]http://www.w3.org/2014/10/27-tt-minutes.html#action01]



   <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

   2014-11-03].



   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

   TTML



   <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

   [20]http://www.w3.org/2014/10/27-tt-minutes.html#action02]



   <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 §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.

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

   instance.

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

   procedure.

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

   could

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

   require

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

   document.



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



   <Cyril>

   [21]https://dvcs.w3.org/hg/html-media/raw-file/default/media-so

   urce/byte-stream-format-registry.html



     [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

   designator.



   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

   attribute.

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

   DASH.



   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

   TTML]

   ... Takes us through the proposed changes to 14496-30.



   group discusses track selection behaviour based on aspect

   ratio.



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



     [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

   [23]http://www.w3.org/2014/10/27-tt-minutes.html#action03]



   <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

   comments.

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

   [24]https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttm

   l-imsc1-20140930/2968?cid=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

   answered.



   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

   purpose.

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

   SMPTE, EBU and DECE.



   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

   groups.



   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

   [25]http://www.w3.org/2014/10/27-tt-minutes.html#action04]



   <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

   forcedDisplay.

   ... 5.7.4 - I should be able to implement the proposal and the

   typo.

   ... 5.10 - this is a good suggestion a priori

   ... 6.3 - This is a good point - I should link to 9.3.1 in

   TTML1

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

   [27]http://www.w3.org/2014/10/27-tt-minutes.html#action02]

   [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

   [28]http://www.w3.org/2014/10/27-tt-minutes.html#action01]

   [NEW] ACTION: nigel Make request to Philip and Silvia to change

   Living Standard to Editor's Draft. [recorded in

   [29]http://www.w3.org/2014/10/27-tt-minutes.html#action03]

   [NEW] ACTION: nigel Scribe notes on CR exit criteria for IMSC 1

   based on meeting debate [recorded in

   [30]http://www.w3.org/2014/10/27-tt-minutes.html#action04]



   [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 01:53:54 UTC