- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 21 Nov 2013 16:29:18 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CEB3E54F.14CF5%nigel.megitt@bbc.co.uk>
Minutes for 15/11/13 can be found at: http://www.w3.org/2013/11/15-tt-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Timed Text Working Group Teleconference
15 Nov 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/11/15-tt-irc
Attendees
Present
(BBC), (Opera), Giuseppe, Glenn, Ishida, Israel,
Kepeng_Li, Mark, Nigel, Olivier, Pascale,
Pierre_Anthony, Richard, Sylvia, Thereaux, Thierry,
Vickers
Regrets
Chair
nigel
Scribe
silvia
Contents
* [3]Topics
1. [4]Introductions
2. [5]state of TTML1 Animation
3. [6]Inline Regions
4. [7]Readability and IMSC redux
5. [8]WebVTT
6. [9]testing
7. [10]Converging WebVTT and TTML
8. [11]TTWG Roadmap
9. [12]Converging WebVTT and TTML
10. [13]wrap-up
* [14]Summary of Action Items
__________________________________________________________
<trackbot> Date: 15 November 2013
<glenn> we should have the phone situation fixed shortly
Introductions
<nigel> Nigel Megitt, BBC
<nigel> Glenn Adams Cox
<igarashi> Tatsuya Igarashi SONY
<pal> Pierre-Anthony Lemieux, supported by MovieLabs
<tmichel> Thierry Michel W3C
<mijordan> I get the message that the conference is restricted.
<olivier> scribenick: olivier
<mijordan> I'm in.
<glenn>
[15]https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2
013-TTMLAnimations.pdf
[15] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2013-TTMLAnimations.pdf
<mijordan> Michael Jordan, Adobe
glenn: presents slides on state of TTML1 Animation
state of TTML1 Animation
glenn: now moving to things we want to have in TTML2
(Huawei)
pal: want to question third assumption - about continuous
animation
glenn: let's move on, will address later
nigel: the issues we are trying to tackle are on the agenda, we
can address them in time
<glenn> – h8p://www.w3.org/wiki/TTML/changeProposal001
<glenn> [16]http://www.w3.org/wiki/TTML/changeProposal001
[16] http://www.w3.org/wiki/TTML/changeProposal001
<nigel> [17]http://www.w3.org/wiki/TTML/changeProposal001
[17] http://www.w3.org/wiki/TTML/changeProposal001
glenn: still presenting from
[18]https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2
013-TTMLAnimations.pdf, now on slide 10
... change proposal -
[19]http://www.w3.org/wiki/TTML/changeProposal001
... any question on element targeting?
... most of the issues will be discussed in the next section
... issue of target element was raised by Sean
[18] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/design/TPAC2013-TTMLAnimations.pdf
[19] http://www.w3.org/wiki/TTML/changeProposal001
<nigel> [20]https://www.w3.org/AudioVideo/TT/tracker/issues/22
[20] https://www.w3.org/AudioVideo/TT/tracker/issues/22
pal: who filed this issue and cared about this?
... re - [21]https://www.w3.org/AudioVideo/TT/tracker/issues/22
... have action item to follow up with Mike Dolan on this
... feedback was - it doesn't seem to be an urgent requirement
[21] https://www.w3.org/AudioVideo/TT/tracker/issues/22
mijordan: concern in not having something like this
... having a shorthand way to define this like CSS does
... could be a better way and reduce complexity
glenn: agree
pal: one of the proposals is to allow sequence of set commands
... previous slides had suggestions on how to address that
... without need for continuous animation
mijordan: is the transition between css animation and our
syntax going to be a problem then?
<pal> @giuseppep yes, it was filed in 2008
glenn: this problem has come up so many times in the past
... seems a no-brainer to me
... implementations are already there
... we just need to integrate it so it's reasonably useful
... if you want to do smooth animation of opacity
... you'd end up with a lot of set elements
mijordan: dealing with discrete steps is more processor
intensive and painful
glenn: implementations are starting to use GPU for such
animations
... back to slide set
<glenn>
[22]https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttm
l2.html#animation-vocabulary-animate
[22] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#animation-vocabulary-animate
glenn: looking at current TTML2 draft
... does look quite complicated, there are a lot of attributes
there
... people's comments has been "do we need all this complexity"
... went through CSS animations
... with @@
... we looked at what was supported by CSS animations
... and which were syntactic sugar
... conclusion was we could remove about 8 of these attributes,
for different reasons
... reducing parsing complexity, down to something similar to
what set has
... lists attributes which are different from set
... 5 attributes would be added
... back to slode set. Now: continuous animation (2)
... accumulate and additive
... not currently supported by css animation. propose to defer
support
... need to introduce multi-valued style property expression
... next - repeatcount and repeatdur, both in SVG. propose only
supporting repeatcount
<glenn>
[23]http://www.w3.org/TR/2001/REC-smil-animation-20010904/
[23] http://www.w3.org/TR/2001/REC-smil-animation-20010904/
glenn: shows examples of different calcmodes
... paced mode not necessary, can be expressed as linear
... what next
... want to get buy-in to simplify by removing 8 attributes
... and not yet try to deal with the issue of supporting
multiple contexts for out of line animations
... other issue was brought up by pal
link to the issue?
<nigel> I don't think it's logged as an issue
glenn: right now we only have inline-form of set
... two options
... 1 have out of line animate or set element point to target
element
... 2. have target element point at the animate or set element
... latter more consistent with the way we currently do
pal: that was not part of your proposal
glenn: no proposal in writing
pal: [looking for issue]
<nigel> issue-227?
<trackbot> issue-227 -- <p> fade-up and –down -- closed
<trackbot>
[24]http://www.w3.org/AudioVideo/TT/tracker/issues/227
[24] http://www.w3.org/AudioVideo/TT/tracker/issues/227
pal: it's issue-227 -
[25]http://www.w3.org/AudioVideo/TT/tracker/issues/227
[25] http://www.w3.org/AudioVideo/TT/tracker/issues/227
glenn: we closed it because thought it was a duplicate of
issue-22
pal: can take action item to sort it out
... to reopen the issue and add details
glenn: suggest adding new issue
<glenn> proposed issue title: permit reuse of animation
constructs by allowing multiple content elements to reference
same out-of-line animation declaration
<glenn> ... this reuses the same semantics as TTML uses for
style/layout, where content elements point at style/layout, and
not other way around
nigel: there was a proposal in presentation
... to acheive same functionality by @@
pal: happy with issue text/title suggestion
<glenn> raise issue: Permit reuse of animation construct(s) by
allowing multiple content elements to reference same
out-of-line animation declaration
<nigel> ACTION: pal to raise this issue [recorded in
[26]http://www.w3.org/2013/11/15-tt-minutes.html#action01]
<trackbot> Created ACTION-239 - Raise this issue [on
Pierre-Anthony Lemieux - due 2013-11-22].
nigel: time check
glenn: have already recorded editorial notes in the draft
... propose to implement those changes
nigel: any objections?
pal: none
resolution reached
Inline Regions
<nigel> issue-176?
<trackbot> issue-176 -- Adding support for extent and origin
attributes on block elements -- open
<trackbot>
[27]http://www.w3.org/AudioVideo/TT/tracker/issues/176
[27] http://www.w3.org/AudioVideo/TT/tracker/issues/176
glenn: already in ttml2 draft
... section 7.1.4 div
... added layout.class in content for div
nigel: will that inherit any style attribute from anywhere?
... initial values are well defined
... inheritance is an open issue
issue-277?
<trackbot> issue-277 -- Adding style inheritance for regions.
-- open
<trackbot>
[28]http://www.w3.org/AudioVideo/TT/tracker/issues/277
[28] http://www.w3.org/AudioVideo/TT/tracker/issues/277
glenn: strong preference?
... inherit from layout element or root element?
... we could have several layout elements
nigel: you imply that you could @@
[scribe missed discussion]
glenn: maybe we should defer, as not directly related to agenda
item
... agenda is about use of shorthand properties
issue-176?
<trackbot> issue-176 -- Adding support for extent and origin
attributes on block elements -- open
<trackbot>
[29]http://www.w3.org/AudioVideo/TT/tracker/issues/176
[29] http://www.w3.org/AudioVideo/TT/tracker/issues/176
<nigel> nigel: asks if referencing style from layout or tt:tt
would override initial values.
<nigel> glenn: no it wouldn't.
pal: did you capture why it would not be a good idea to do the
same with attributes
glenn: discussed this in teleconferences, should be in minutes
pal: I'm aware of at least 1 software package that has been
using shorthand on <p>s
mijordan: awaiting response from this software vendor
pal: there is a significant catalogue of content generated by
this software
glenn: think point is moot. effect is the same.
... we have great deal of semantics in document about how
regions work
... if we wanted to describe this use, we'd have to redefine
how region work
... this simplifies specification
pal: this is going to break a lot of files
glenn: no - am going to add the shorthand that this company is
using
mijordan: hadn't noticed that either
glenn: we have already decided to basically fork the shorthand
,,,
pal: let's capture exactly what you said, make that a proposal
... and we can move on
glenn: already agreed
... wantedto make sure people were clear on this
... that it won't break existing uses
... albeit proprietary and illegal
... I already have action to implement this
... don't think anything more is needed
action-215?
<trackbot> action-215 -- Glenn Adams to Specify special
semantics for tts:{extent, origin} on content elements to map
to new inline region feature -- due 2013-10-10 -- OPEN
<trackbot>
[30]http://www.w3.org/AudioVideo/TT/tracker/actions/215
[30] http://www.w3.org/AudioVideo/TT/tracker/actions/215
glenn: don't think we need new resolution
pal: at least someone should respond to michael
glenn: think I already have
pal: should be recorded in the issue
<glenn> ISSUE-176: Note that Action-215 will adopt support for
tts:{extent,origin} directly on <p> as a shorthand for
specifying an inline region.
<trackbot> Notes added to ISSUE-176 Adding support for extent
and origin attributes on block elements.
nigel: review agenda -
[31]http://www.w3.org/wiki/TimedText/tpac
[31] http://www.w3.org/wiki/TimedText/tpac
pal: can we close action-205?
<nigel> issue-205?
<trackbot> issue-205 -- TTML probably shouldn't have adopted
xml:id instead of id. -- open
<trackbot>
[32]http://www.w3.org/AudioVideo/TT/tracker/issues/205
[32] http://www.w3.org/AudioVideo/TT/tracker/issues/205
<nigel> action-205?
<trackbot> action-205 -- Michael Jordan to Forward this
solution to relevant implementers for their input -- due
2013-09-26 -- OPEN
<trackbot>
[33]http://www.w3.org/AudioVideo/TT/tracker/actions/205
[33] http://www.w3.org/AudioVideo/TT/tracker/actions/205
pal: suggestion to close 205
glenn: close as OBE
nigel: your suggestion is equivalent to what was implemented?
glenn: yes, that's the intent
Readability and IMSC redux
ISSUE-286?
<trackbot> ISSUE-286 -- Extend the background area behind
rendered text to improve readability -- open
<trackbot>
[34]http://www.w3.org/AudioVideo/TT/tracker/issues/286
[34] http://www.w3.org/AudioVideo/TT/tracker/issues/286
nigel: discussed a little on Monday
... about extending background around rendered text
<glenn>
[35]http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.
html
[35] http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.html
nigel: subtle difference betweenn what this does and what this
achieves
... demo
... demo resizing the viewport
<glenn>
[36]http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.
html
[36] http://lists.w3.org/Archives/Public/public-tt/2013Nov/0031.html
nigel: when shrinking, new line appears but without the extra
padding
glenn: shows ublic/public-tt/2013Nov/0031.html
nigel: promising
... if we can translate that into TTML syntax
... we will have achieved requirement
... going back to padding issue
... this padding would affect layout, whereas request from EBU
was that it should not
... think this is minor issue
glenn: depends if you want to stick to what can be mapped with
CSS
... questionable and risky path
... if browsers are just going to use CSS to render TTML
... two ways
... 1. define real padding and align properties and define how
they map to CSS
... 2. or use properties that are already there, on content
element
... however we didn't add anything to do the cloning of padding
... similar for row align
nigel: with EBU hat on, would be nice if there was
compatibility
... but with TTWG hat on, is there any preference?
glenn: it requires more editing and syntax
... if instead of creating new row padding you use existing,
burden of editing and testing is lower
nigel: but then so would the other option
mijordan: simple solution
... can be solved by using inline-block span element
glenn: in CSS?
mijordan: we don't have a way of defining margin on either side
... but a span as inline-block would just work
<pal> (nice minutes, btw.)
glenn: two issues to disentangle
... issue of whether or not we should expose lower level
properties
... and let authors use them to do what they want
... or we could define a proprety that is like EBU-TT, such as
rowpadding
... and affected using a shorthand or a higeher-level
expression which we map to CSS properties
pal: the same discussion has happened or will happen with image
and background image support
... you were thinking more of CSS style
... should we be consistent there?
glenn: in TTML1 we have not introduced any style properties
... extent and origin were the closest we came
... tried to avoid defining new properties
... if they are effectively shorthand for some subset of CSS or
XSL-FO, it doesn't seem quite as bad as introducing completely
new properties
... not adopting a fixed position on this at this point
pal: one data point is - some folks have already taken a
specific approach
... we probably want to reulse what others have done
... unless there is a good reason not to do that
... am personally happy to have editor go back and look at
those three and suggest consistent approach
nigel: we can do something sufficiently close to requirement
with HTML and CSS
... now we need to translate it in TTML
glenn: my effort to come up with CSS examples was a first
excercise
... useful
... we'd have to work around fact that diff browsers implement
flex differently
... if people want to propose, they should provide css/html
that demonstrates it is feasible
mijordan: good way to deal with it
nigel: we have demonstrated we can do it
... now need to think about how
... issue remains open
glenn: action on me to propose and draft spec for some solution
pal: suggest have list of action-tpac-2013 for folks not here
nigel: [break]
<nigel> trackbot, start meeting
<trackbot> Meeting: Timed Text Working Group Teleconference
<trackbot> Date: 15 November 2013
<dsinger_> zaki, who is here?
<nigel> scribeNick: nigel
<scribe> chair: dsinger
nigel: welcome Silvia and David to TTWG!
dsinger: it's a pleasure to be here
... introduces topics from agenda
WebVTT
silvia: introduces herself. Editor of the spec, taken over from
Ian Hickson
[37]http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
[37] http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
+Present, cyril, plh
silvia: the spec and editor's draft are currently identical
... THere's no WhatWG version now.
page: WebVTT Features
silvia: Why WebVTT?
... We wanted something in track element in HTML5 to provide
timeline cues.
... For audio descriptions, chapters, subtitles, other timed
metadata
... CEA 608/708 Features all met.
nigel: WSTTeletext?
silvia: at the beginning we looked at a lot, but haven't
verified against teletext
plh: how does the concept of chapter relate to MPEG4?
silvia: it's like DVD chapters
plh: what do you expose to users?
silvia: depends on what tracks you put in
dsinger: we expect the author to resolve conflicts
silvia: we must satisfy legal requirements
... captions and subtitles implemented more than other user
interface elements for that reason.
... we have menus for captions and subtitles to select desired
tracks
... We wanted to allow the web page developer to override
formatting in the caption with CSS
... Anything that's rendered on the webpage should be
overridable by CSS
<dsinger_> we've certainly had (in the past) pop-up menus on
the controller showing chapter names (e.g. for DVD) but I don't
know the state or the plan for <track> chapter lists
silvia: We have some extensions that should at some point be
brought back into HTML
questions?
dsinger: lots of work has been to meet FCC requirements and
bugs have been filed and resolved.
plh: asks re bugs
silvia: about to get there
... FCC reqs lead us to introducing regions. Browsers didn't
all agree, but now seem to be implementing.
... req is for roll-up and padding, and to allow changes in
background colour.
nigel: why was a new format needed for text track cues?
silvia: it could have been done in js but that didn't meet
usability requirements. when analysing existing formats the
browsers didn't like any of them including TTML.
... it's not a bad position, with WebVTT being good for
distribution and TTML more widely applicable.
israel: which browsers?
silvia: all of them. I did try to get them to use TTML but it
wasn't acceptable.
israel: we have an implementation that supports SDP.
silvia: apologies yes MS IE does support.
plh: IE team was uncomfortable with it for some time before
implementing it
dsinger: both formats are useful and offer functionality to the
industry.
silvia: re MS, different parts of the org had different
opinions
page - bugs
silvia: 46 bugs now. summaries by category
... we want to complete functionality change issues before
handover to WG. And have clear IPR position.
... so want to close off some issues before handover.
... 3 blockers
<dsinger_> we wanted to be clear of the features agreed and
have them reflected in the spec., so that the IPR situation was
as clear as possible. having stuff agreed in the CG but not
represented in the document would have led to a slightly blurry
situation
silvia: want to close off the syntax change, bugs/underspecced
and flesh-out text issues before handover. The first 3 are
blockers, the next 34 can be dealt with in the WG
... We can go to rec without the 8 new feature requests
... the last 1 is an editor's bug
dsinger: are these categories in the tracker?
silvia: no, I should probably add some categories or
classifications or keywords
<scribe> ACTION: silvia to add keywords to bugs in tracker
[recorded in
[38]http://www.w3.org/2013/11/15-tt-minutes.html#action02]
<trackbot> Error finding 'silvia'. You can review and register
nicknames at
<[39]http://www.w3.org/AudioVideo/TT/tracker/users>.
[39] http://www.w3.org/AudioVideo/TT/tracker/users%3E.
note for minutes that silvia has action to add keywords to bugs
in tracker
nigel: there's some admin to do in combining the groups!
next slide: demos
silvia: CPC has done some work - nb firefox doesn't support
webvtt
<nigel_> next slide: tools
<nigel_> silvia: extensions in js - pull up my repository to
experiment
<nigel_> next slide: implementations
<nigel_> silvia: there's a track element in HTML5 that uses
WebVTT as one of the file formats to get cues into the browser.
Supported in all browsers (firefox nightly not release)
<nigel_> ... IE doesn't support regions yet
<nigel_> ... Chrome has implemented regions behind the flag
<nigel_> ... Safari has it too, as they were based on same
rendering engine
<nigel_> ... Opera also
<nigel_> ... Opera was first to implement full WebVTT spec.
Implementor is now part of the blink community.
<nigel_> glenn: the region support is not yet in the shipping
version of chrome - will be in the new version of Chrome32
supported by runtime flags.
<nigel_> ... currently behind a compile time flag
<nigel_> silvia: Firefox is working on it. Developer meetup at
the weekend: all of the browsers except IE will be discussing
state of VTT implementation. At foms workshop in SF
<nigel_> glenn: link in IRC?
<silvia> [40]http://foms-workshop.org/
[40] http://foms-workshop.org/
<nigel_> next slide: REC track
<nigel_> silvia: Process. How to make WebVTT a ratified
standard? Been talking about it in W3C. Come to an agreement to
bring into TTWG as part of the re-charter.
<nigel_> dsinger: The transition process. The CG process is not
the same as the WG process. In CGs members only give royalty
free grants on their own contributions.
<nigel_> ... There's a Final Spec Agreement process to allow
the chair to extend the IPR commitment to the whole document.
To do that transition it's well advised if not mandatory to
have a clear IPR position
<nigel_> ... before bringing into the WG.
<nigel_> ... I have approval from Apple to sign. I'm eager to
start the process and confident that others will follow suit.
<nigel_> silvia: and I need to complete those issues!
<nigel_> dsinger: that will then become a public draft. We can
then move into normal Rec track issues.
<nigel_> ... We need to think about mapping from TTML to VTT
and the reverse. Sean Hayes came up with a good point that we
should discuss common semantic models.
<israelh> q
<nigel_> glenn: re the FSA you're going to use that to go to
the Rec track. Then the question arises re continuing
development. My understanding is that folks would mostly like
to continue
<nigel_> ... in the CG. Does that mean that every transfer from
CG to WG has to have its own FSA?
<nigel_> dsinger: that's what I would do. An outstanding
question is how we maintain the CG and WG docs, it's hard work
for the editor.
<nigel_> all: why do both?
<nigel_> dsinger: use CG for experimental bits only
<nigel_> silvia: there are many CG members who are not W3C
members so we can't force them into the TTWG
<nigel_> ... I'd prefer them in the WG and have the discussions
there.
<nigel_> israel: I understand that the CG purpose is to migrate
into the WG eventually. That doesn't prevent creation of other
CGs that are in parallel or build on this.
<nigel_> ... to have both seems redundant process-wise.
<nigel_> giuseppep: isn't it going to create more frgmentation?
<nigel_> pal: the goal of the WG is to be the single place
<nigel_> silvia: the CG has the same goal
<nigel_> wide objections to the idea that they can do the same
thing
<nigel_> israel: is it fair to say we should get a view from
plh?
<nigel_> dsinger: yes
<nigel_> cyril: the work of the two teams should be clearly
distinguished e.g. call the CG 'extensions'
<nigel_> pal: the setup of the groups defines what they can
achieve re international standards
<nigel_> dsinger: we can have a CG for experimental discussions
and even generate reports into the WG. I doubt we will need 2
specifications in the future.
<nigel_> ... we'll have an active community. We should only
discuss forking specs when that situation arises.
<nigel_> israel: hasn't this happened before with WhatWG?
<nigel_> silvia: there's a big misunderstanding here. Any CG
developments will be extension specs - it's not that both will
work on the same spec. That would be a nightmare for me to
maintain.
<nigel_> ... This is why we're doing a FSA so that by that time
it's feature complete and any new discussions will create new
features.
<nigel_> ... we've done extension specs before e.g. regions.
<nigel_> silvia: we can also take views from implementors.
<nigel_> dsinger: in the process of doing this it's a first for
W3C to go from CG to WG. Let's set a good example.
<israelh> israelh
<nigel_> nigel: how will you resolve requirements inputs from
both the CG and mapping from TTML?
<nigel_> silvia: the people interested in each format (VTT and
TTML) overlap but are separate. I'd like to keep the ...
<nigel_> dsinger: TTWG keeps its discussions in public.
<nigel_> silvia: I've heard that people don't want to pollute
the TTWG mailing list with VTT issues. Both lists are public
and can be referenced.
<nigel_> dsinger: there may be a best practice email header
<nigel_> glenn: one reason for bringing the two groups together
is to increase shared understanding. To that extent two mailing
lists may be a barrier. On the other hand it's an evolutionary
process.
<nigel_> ... We can move forward one step at a time. Nobody on
TTWG has said they don't want to see VTT. Actually neither
group has a lot of traffic compared to some.
<nigel_> glenn: because TTWG is public anyone can join the list
without being a group member.
<nigel_> dsinger: I'm sure I'll be talking with nigel about
feature mismatches and if they are likely to be shared or not,
and suggest actions to share info.
<nigel_> silvia: in HTML WG they created spec-related mailing
lists for task forces. We can consider the CG a task force.
<nigel_> heads nod
<dsinger_> I expect the chairs to be steering conversations to
the appropriate mailing list - e.g. far-off features to the CG,
bugs in the text to the WG
<nigel_> israelh: I'd like to explore the inter-transformation
between TTML and WebVTT and the mappings. Enthusiastic about
this work.
<nigel_> ... the more we can see how these come together the
easier it is to justify spending internally
<nigel_> nigel: we have great expertise in the two groups which
we should make the most of for the sake of users and the
audience.
testing
<nigel_> silvia: we have no tests at the moment - there's a lot
of work to do on the rec track here.
<nigel_> glenn: opera has lots of tests that are available.
<nigel_> silvia: there are lots available they're just not part
of the W3C suite.
<nigel_> dsinger: it would be good to have a test lead.
<nigel_> glenn: cyril seems like a good candidate.
<nigel_> israelh: re the review of status you mentioned
regulatory mappings. Can you give a summary of how closely
they're met?
<nigel_> dsinger: we should pull up the bug/wiki page.
<nigel_> ... we went through the text of the FCC ruling which
was very specific about some features based on 608. We tried
5-10 designs to meet roll-up and regions but they didn't meet
the word of the
<nigel_> ... regulations. We ended up just meeting them very
precisely.
<nigel_> israelh: we were doing that too with TTML, so it would
be good to get feedback on how user controls to overwrite
specifications map to the regulations
<silvia>
[41]https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVT
T/608toVTT.html
[41] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
<nigel_> silvia: There's more than one spec in the CG. I have a
608 to WebVTT spec (link above)
<nigel_> silvia: We walked through all the issues and collected
them into the spec.
<nigel_> ack
<nigel_> nigel: did you consider performance as part of the 608
regulatory work?
<nigel_> silvia: WebVTT is simple enough that the performance
should be fine.
<nigel_> ... But nobody has ever done any measurements.
<silvia> … we've only taken subparts of the HTML/CSS feature
set
<nigel_> dsinger: We should review the regulatory compliance
again especially wrt user controls
<nigel_> israelh: another interesting topic is, from the apps
world, once the user configures the settings should there be an
API to query them?
<nigel_> silvia: the Indie UI people are looking at this.
<nigel_> dsinger: you can react to a visual acuity problem for
example.
<nigel_> nigel: timecheck
<dsinger_> I should also mention the MPEG work for packing TTML
and VTT into 'MP4' files: ISO/IEC 14496-30 Information
technology — Coding of audio-visual objects — Part 30: Timed
text and other visual overlays in ISO base media file format
<nigel_> group thanks cyril for making that happen
<nigel_> group breaks for lunch
trackbot, start meeting
<trackbot> Meeting: Timed Text Working Group Teleconference
<trackbot> Date: 15 November 2013
<silvia> scribe: silvia
Converging WebVTT and TTML
nigel: what are sensible deliverables in the area of
convergence
… feeds into the roadmap discussion at 2pm
… we could start with a quick summary of the underlying models
dsinger: was raised by Sean
… could ask silvia to give a quick overview of the WebVTTmodel
… then glenn with a model for TTML
pal: I'd like to understand what the question is that we're
trying to answer
nigel: we're trying to work out the best deliverables for the
WG given the co-existence of TTML and WebVTT
dsinger: I think Sean wanted a semantic conversion to make sure
we get commonality in behaviour
… if there are needless differences, we can iron them out
mark: the Web & TV interest group had a task force that was
tasked with that
there's a link on the agenda
[42]http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
[42] http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
nigel: might be the best starting point
plh: hi - I cannot be in this room from 2 onwards
[room discussed to maybe jump straight to the charter]
nigel: let's reorder the two topics
TTWG Roadmap
<dsinger> we now move to Charter Revision
<dsinger> see
[43]http://www.w3.org/2013/10/timed-text-charter.html
[43] http://www.w3.org/2013/10/timed-text-charter.html
plh: status was that we were ok with it but nigel had some
comments that were not expressed
dsinger: let's just go through it
… plh - go ahead section by section
nigel: goal is to get to have this charter ready by the end of
this session so we can move ahead with taking it to the AC?
plh: after submission to AC, there will be feedback from AC
that needs to be addressed
dsinger: isn't the WG the first one that has to provide input?
plh: it was there 8 months ago
... initial chairs section is proposed to be adapted to contain
Nigel and David
… nigel hasn't said "yes" yet
nigel: 4 things are important to me
… can I do it?
… have I met the people that I will be working with?
… is the group happy for me to do it?
… fourth … was a joke....
plh: I think he's capable of doing so
nigel: I am also a co-chair of the EBU subtitles group
… sometimes I will need to bring EBU input to the group
… we just need to be clear what hat I am wearing
… at any point in time
glenn: let's replace the questionmarks with nigel
plh: Mark Sadecki will help with resolving a11y issues
… Thierry will continue to be the dedicated team contact
… plh is the official team contact and will make time as much
as necessary
nigel: @@ will bring ITU a11y relationship into it, too
<plh> s/@@@/Kawamori/
glenn: let's correct the name of the TTML spec
dsinger: can we remove the word "streamable" from the scope
paragraph, since we are dealing with streamable and
non-streamable content
nigel: we need to make sure it's streamable, because otherwise
it's not useful
mark: this is scope, so let's not rule it out
[group decides to take out this word]
plh: 1.6 - the html mapping is part of the TTML2 spec
glenn: we may take it out … can we change the charter later?
plh: the way it's worded now, yes. it's on the rec track now
glenn: I've already drafted a ttml1 API spec and am working on
a ttml2 API spec for JS API
… we could fold these into the TTML spec or publish separately
… should be included in the scope though
cyril: is this part of what we main by HTML mapping?
plh: yes
dsinger: includes CSS?
plh: includes a mapping to CSS, but not CSS itself
cyril: what does it mean to describe a document as HTML5
… I understand what synchronic document means, i.e. a mapping
glenn: in TTML2 we will have 2 mappings, one XSL-FO and a
HTML-CSS mapping
plh: but we didn't define styling in TTML1
glenn: we use XSL-FO as our didactic framework for explaining
what mapping means
… what brought this up is that WebVTT maps to HTML and CSS
… we're now doing the same for TTML
cyril: let's add the word "document" then (describe TTML
documents as HTML documents or HTML representation in 1.6)
glenn: insert after HTML5 a "document fragment"
… then it's correct
cyril: what is v.next in 1.4 ?
plh: yes, that's TTML2
glenn: we're only working on TTML2 right now
plh: can we change 1.4 then?
dsinger: just remove the word "v.next"
… it's also used in 2.1
glenn: 1.5 replace TTML1.0 with TTML1
cyril: is it on purpose that the metadata part was removed from
section 2 ?
silvia: you don't do rendering of metadata
plh: let's add metadata in
… it wasn't missed on purpose
dsinger: rename v.next in 2.1 into something more nicely
cyril: can we make it explicit that WebVTT is mapped to HTML
dsinger: what is missing for both is "the use of these formats
in a HTML context"
plh: will put it at the top before these paragraphs
cyril: should we include guidelines when to use either format?
… I'm looking at this from the viewpoint of a person outside
the W3C
glenn: we don't do this for xhtml / html either
cyril: that one's obvious: one's xml and the other is not
[general giggles in the room] - thanks cyril!
dsinger: should point 3 rather say that we will develop a
mapping
glenn: it's a bit academic - nobody has asked for this yet
dsinger: since webvtt is being rendered and the industry
produced ttml, it's a real-world issue
plh: it will be part of building the html mappings
glenn: point 4 - do we need to list maintenance specs?
… then we need to also list all the old specs
plh: is there interest in doing point 4?
glenn: we can update a note anytime without asking the AC?
plh: I'll clarify that it is US only
… as a note
cyril: the last deliverable doesn't have a description of the
deliverable
plh: it refers to the last item in the deliverables section - I
need to clarify both
nigel: on point 5, what is meant by "and subset" ?
per: that attempted to say that the profile published by this
group should be a superset of the input document
… objective would be to end up with a superset of what is
subm,itted
nigel: that's dangerous since it implies that we have to adopt
everything of the document
dsinger: let's remove it and leave it for the WG to decide
later
cyril: point 6, refers to "live production", but milestone says
"live update note" in 2.2. milestones
plh: will fix the milestones
dsinger: should we mention a testsuite?
glenn: 1.7 and 2.3 mention it
plh: testsuites are part of process
silvia: do we want to publish the WebVTT to CEA608/708 mapping,
too?
nigel: not necessary for TTML since SMPTE has such a spec
silvia: should it be a note or on REC trac?
plh: prefer a note
dsinger: let's add that we will publish a note at the end of
point 2
... to check that the deliverables list is accurate
glenn: end date of charter is 11 months past the end of the
last deliverable
nigel: there are quite some synchronized timescales that may
create a lot of effort
… are they realistic?
scribe: peakiness of effort
silvia: suggestion to have nigel & plh liaise to change the
dates
pal: the docs are all edited by different people
… all of these docs have drafts, so let's give ourselves some
challenging milestones
dsinger: but the group as a whole has to look at the topics
silvia: we need a first column for FPWD on all of them
… in particular, WebVTT prefer FPWD in January
plh: what should the other dates be?
dsinger: reviews WebVTT milestones
silvia: I am mostly concerned about the testsuite
israelh: I don't know what we're missing in IE for WebVTT
support
dsinger: I don't think we have all browsers interoperably
support WebVTT by June next year
plh: the new process is not yet available to us
… once the new process comes out, it is what drives us
dsinger: once the new process has been adopted, we have to
change the charter
plh: only need to change the milestones
dsinger: september for PR for vtt
pal: TTML2 and its profile - I'd look to Glenn for advice
… extremely aggressive
plh: safari implements webvtt?
dsinger: yes, it's in webkit
nigel: have we sorted out the timescales?
dsinger: let's have the FPWD before xmas
… for webvtt
<plh> CR for WebVTT in September
… section 3
pal: do we have a normative reference to HTML? no
dsinger: are we missing dependencies
?
nigel: can we get the TAG to review the scope of the
deliverables?
plh: you can't force the TAG to do this
dsinger: as a chair you can ask them for input
nigel: I wish to
Thierry: why is SVG a liaison and not a dependency?
dsinger: we don't need the SVG group to make any changes
cyril: we need to make specs based on the web animations spec
pal: since the spec is still draft, I'd call it a dependency
glenn: I discussed with the SVG chair
dsinger: we're adopting something that's specified in the
future, so let's make it a dependency
plh: you will need a review from the groups listed under
dependency
cyril: it would be good for SVG WG to review the animation
section
glenn: we're adopting what is exactly specified in SVG 1.1
… so it's not a dependency, just a liaison
[group mumble: ok]
plh: there is an issue with TextTracks CG
dsinger: they explore and we adopt
plh: where will the discussion happen?
dsinger: exploratory stuff in the CG, stuff on the REC track is
in the WG
pal: the key aspect is there will be only one home for the
spec, which is this group
… discussions related to the WebVTT group will take place on
the TTWG list
plh: will need to think this through
dsinger: extension specs can be created in CG
plh: I have more generally an issue to figure out how CG and WG
work together
nigel: there is a risk that communications get split
… and decisions get made in one group that the other group
doesn't agree with
<mark_vickers> mark_vickers_vickers has joined #tt
pal: there is nothing that this group can do from stopping
other people to do something that we don't like
plh: if I'm bringing a new feature to the spec, I don't want to
be told to go speak with the CG
nigel: if a feature gets raised as part of developing the
mapping between ttml and vtt, we don't want to have to push
this to cg
dsinger: things we need to do to complete our deliverables
obviously need to be done here
cyril: new extension proposals for vtt would be good to be
passed by the CG as well
dsinger: we absolutely need to manage our communication
nigel: is it a liaison with the TextTrack CG?
… it's much tighter than that
… are they a dependency?
pal: I think that people have a concern with the VTT spec, they
should come to this group
nigel: we don't have a dependency though
dsinger: how about i18n
nigel: that's a liaison with i18n
plh: what about asia's presence in TTWG
dsinger: would be good to add i18n
glenn: we have requests for ruby in TTML
pal: if we're missing a group, we can still liaise with them
later, right?
dsinger: let's add i18n to liaison
<nigel> add dvb-tm
nigel: let's add the DVB-™ to external gropus
<plh> zdvb-TM
<plh> DVB-TM
mark_vickers: should we add the FCC?
dsinger: no, we just execute what they write
plh: what about ITU?
... is there a group that's relevant?
pal: yes, I'm still unclear what they do
… a group about TimedText
… FG AVA
<pal> ITU FG AVA
<pal>
[44]http://www.itu.int/en/ITU-T/focusgroups/ava/Pages/default.a
spx
[44] http://www.itu.int/en/ITU-T/focusgroups/ava/Pages/default.aspx
dsinger: let's send them a liaison
pal: I don't have a liaison in mind
… possibly in future
plh: an effective way for this is if they have a person sitting
on both sides
… mpeg, SMPTE, EBU we are covered
… DECE we are covered
scribe: DVBTM?
nigel: colleague of mine, so we're ok
Moving to section 4 … ok
section 5....
we'll update the web page once the charter is approved
plh: probably DEC/JAN
dsinger: should we add the wiki?
plh: too much detail
section 6...
Thierry: should we add the vtt mailing list?
dsinger: no, matters related to our deliverables go here
plh: conventions for mailing list should be mentioned
pal: how about the bug tracker?
glenn: some groups like HTML use issues when bugs become larger
issues that need to be handled differently
pal: I prefer bugzilla for tracking bugs over the issue tracker
nigel: this is not part of the charter discussion
section 6, 7, 8 are boilerplate, so ok
cyril: what's the license?
plh: W3C document license
… I don't want to use anything else?
silvia: I think we need an open license on the vtt spec
plh: the open document license is currently experimental in
HTML and not approved by TAG for other specs
dsinger: need to get it to the attention to AC & AB for CG to
WG transition
nigel: what about new specs?
<dsinger> ACTION: dsinger to consider the problem of the
license change from CG to WG, with the AC and AB and staff
[recorded in
[45]http://www.w3.org/2013/11/15-tt-minutes.html#action03]
<trackbot> Created ACTION-240 - Consider the problem of the
license change from cg to wg, with the ac and ab and staff [on
David Singer - due 2013-11-22].
silvia: new specs created in WG will go under W3C document
license
plh: a different license will delay the charter
<silvia1> dsinger: if there is discussion in the CG about it,
that can be brought to the AC/AB
<silvia1> ACTION: plh to edit charter by next tuesday [recorded
in [46]http://www.w3.org/2013/11/15-tt-minutes.html#action04]
<trackbot> Created ACTION-241 - Edit charter by next tuesday
[on Philippe Le Hégaret - due 2013-11-22].
<silvia1> plh: ac review of charter is 4 weeks
Converging WebVTT and TTML
<silvia1> nigel: input from Web & TV IG
<silvia1> pal: was a group effort
<nigel>
[47]http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
[47] http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input
<silvia1> … was in response to reacting to two related efforts
in W3C
<silvia1> … Web & TV IG had a taskforce
<silvia1> … recommendation is to combine the two under one roof
<silvia1> … that's done, so that's great
<silvia1> … maximize consistency between the two specs
<silvia1> … three strategies to achieving this:
<silvia1> … * define fully specified mappings
<silvia1> … * pick one and run with it
<silvia1> … * have multiple specs and deal with it
<silvia1> … group didn't express a preference
<silvia1> … also desire to reduce the number of TTML profiles
<silvia1> … to simplify the life of developers and implementers
<silvia1> … finally encourage the TTWG to engage with user and
other groups with similar interest
<silvia1> cyril: there are 3 profiles in TTML
<silvia1> nigel: possibly more, depending on how you count them
<silvia1> pal: w3c only defined 1 profile (simple delivery)
<silvia1> … other groups defined more profiles
<silvia1> nigel: all the profiles are subsets
<silvia1> cyril: then there are 2 profiles: the full profile
and the SDP
<silvia1> glenn: let's not discuss this here
<silvia1> … we're introducing content profiles for the first
time in TTML2
<silvia1> pal: it was a reaction to the market place
<silvia1> … to the wide range of profiles in use in practice
<silvia1> … as an encouragement for the group to take this into
consideration
<silvia1> dsinger: was the Web & TV IG expecting a reaction to
that?
<silvia1> … they name the groups that they want us to interact
with?
<silvia1> nigel: can we assume that the charter has them
covered?
<silvia1> dsinger: can the Web & TV IG propose any others to
add?
<silvia1> mark_vickers: please send a request to IG
<silvia1> action on mark_vickers to ask IG to provide input in
external groups list in new charter
<trackbot> Error finding 'on'. You can review and register
nicknames at
<[48]http://www.w3.org/AudioVideo/TT/tracker/users>.
[48] http://www.w3.org/AudioVideo/TT/tracker/users%3E.
<silvia1> action mark_vickers to ask IG to provide input in
external groups list in new charter
<trackbot> Error finding 'mark_vickers'. You can review and
register nicknames at
<[49]http://www.w3.org/AudioVideo/TT/tracker/users>.
[49] http://www.w3.org/AudioVideo/TT/tracker/users%3E.
<silvia1> action mark_vickers to ask IG to provide input in
external groups list in new charter
<trackbot> Error finding 'mark_vickers'. You can review and
register nicknames at
<[50]http://www.w3.org/AudioVideo/TT/tracker/users>.
[50] http://www.w3.org/AudioVideo/TT/tracker/users%3E.
<silvia1> action nigel to action mark_vickers to ask IG to
provide input in external groups list in new charter
<trackbot> Created ACTION-242 - Action mark_vickers to ask ig
to provide input in external groups list in new charter [on
Nigel Megitt - due 2013-11-22].
<silvia1> dsinger: we've decided to do 3.2 from the IG document
<silvia1> mark_vickers: I need a means to mechanically
translate vtt and ttml into each other
<silvia1> … there isn't a definition right now
<silvia1> dsinger: there may be some things we can't translate,
so we can't aim for completeness, but for consistency
<silvia1> pal: there may be other options for content owners
that have huge collections of TTML files that need to render
their content
<silvia1> dsinger: I want there to be a consistent conversion,
and if features get dropped, then that needs to be clear
<silvia1> … you can always deliver your TTML in other ways
<silvia1> mark_vickers: we don't want people at the end of the
pipeline that need captions to miss out
<silvia1> … I'm in the middle of that pipeline of formats that
are both developed by the W3C
<silvia1> … let's find a way to solve this as a practical thing
<silvia1> israelh: what is the state machine to make this
conversion
<silvia1> nigel: this problem space has been solved by the EBU
to restrain how things get represented in EBU so that
conversions can be done lossless
<silvia1> … can we constrain the problem to make it solvable
<silvia1> silvia: let's not discuss this problem here, because
we have an explicit new charter deliverable for creating a
mapping between webvtt and ttml
<silvia1> … we are discussing an artificial problem that we
don't even know we will have
<silvia1> israelh: are we making it part of the deliverable to
prescribe when the conversion is to be applied?
<silvia1> dsinger: it will be what we make it
<silvia1> nigel: if we start with mapping ttml to html+css then
we have a common language that we both speak
<silvia1> dsinger: we could have a face-to-face to explain to
each other how to do different things
<silvia1> mark_vickers: should there be a milestone in the
charter for such a deliverable?
<silvia1> dsinger: it's already a deliverable, but without a
milestone
<silvia1> nigel: happy with that
<silvia1> silvia: is it a note or on the REC track?
<silvia1> dsinger: a date would be good to have in there to
make us feel bad about it
<silvia1> … if we get to REC on TTML2 and VTT and don't have a
mapping, then it's bad, because we can't make changes any more
<silvia1> plh: editing the charter
<silvia1> … proposed to be a note in october 2014
<silvia1> … going back over the dates in the milestones table
<silvia1> glenn: PR in December would be better
<silvia1> .. and March on TTML2 for REC
<silvia1> plh: ok, table updated
<silvia1> silvia: what is "change proposal 5"?
<silvia1> dsinger: thanks for the input of the IG
<nigel> [51]http://www.w3.org/wiki/TTML/changeProposal005
[51] http://www.w3.org/wiki/TTML/changeProposal005
<silvia1> glenn: this is the mapping of TTML2 to HTML5
<silvia1> … it's on the charter
<silvia1> … no need to discuss further
<silvia1> nigel: plan of action
<silvia1> … we have a new charter drafted
<silvia1> dsinger: the group is too small - can we get more
people to become active?
<silvia1> nigel: not everyone is here
<silvia1> nigel: break
<nigel> dvb link: [52]http://www.dvb.org/groups/TM
[52] http://www.dvb.org/groups/TM
<nigel> issue-295?
<trackbot> issue-295 -- Remove code point restrictions from
IMSC -- open
<trackbot>
[53]http://www.w3.org/AudioVideo/TT/tracker/issues/295
[53] http://www.w3.org/AudioVideo/TT/tracker/issues/295
<nigel> issue-296
<trackbot> issue-296 -- Remove xml:lang placement restrictions
from IMSC -- open
<trackbot>
[54]http://www.w3.org/AudioVideo/TT/tracker/issues/296
[54] http://www.w3.org/AudioVideo/TT/tracker/issues/296
<nigel> issue-296
<trackbot> issue-296 -- Remove xml:lang placement restrictions
from IMSC -- open
<trackbot>
[55]http://www.w3.org/AudioVideo/TT/tracker/issues/296
[55] http://www.w3.org/AudioVideo/TT/tracker/issues/296
<nigel> proposal: remove restriction of a single xml:lang per
document
<nigel> r12a: lang can be used for spellchecking, styling and
other features.
<nigel> no objections: proposal accepted.
<nigel> issue-296: proposal accepted, pal to make edit
<trackbot> Notes added to issue-296 Remove xml:lang placement
restrictions from IMSC.
<nigel> issue-295?
<trackbot> issue-295 -- Remove code point restrictions from
IMSC -- open
<trackbot>
[56]http://www.w3.org/AudioVideo/TT/tracker/issues/295
[56] http://www.w3.org/AudioVideo/TT/tracker/issues/295
<nigel> pal: has concern with reasoning in the issue
description but the text in IMSC does have issues that need to
be fixed.
<nigel> ... Following discussion with Richard Ishida, Glenn and
others, there's a revised proposal.
<nigel> pal: 3 separate concerns expressed.
<nigel> First is last para, to remove inference that limited
character sets in client implementations are acceptable and
recommended.
<nigel> pal: IMSC doesn't intend this. Annex A are
recommendations to the author as to which characters should be
used for specific characters.
<nigel> ... Not a restriction on implementations.
<nigel> r12a: It's a set of recommendations for the minimum set
of characters that authors would be expected to use rather than
should use. What's meant is that authors should have access to
fonts with these character sets as a minimum.
<nigel> pal: The end result is that if I'm an author and I
specify language=fr this is guidance for which characters
should be available.
<nigel> glenn: IMSC is designed to be a content profile only.
<nigel> dsinger: refers to example from 3GPP work.
<nigel> glenn: it isn't a limitation, and what it may contain
is determined by Unicode and by the authoring tools. e.g.
English: we have ASCII, also mathematical bold version of a-z
that could be used. Is someone going to type those on a
composition system?
<nigel> dsinger: is there a document anywhere that maps
language tags to character sets?
<nigel> r12a: yes, it's called CLDR.
<nigel> pal: first step is to agree to make a recommendation
like that and then find the source.
<nigel> glenn: doesn't agree that such a recommendation is a
good idea.
<nigel> r12a: this isn't really about code points and
characters, but about a minimum set of characters you should
have support for in a font.
<nigel> glenn: but this doesn't specify processor minimal
behaviour
<nigel> glenn: nobody needs to be told not to write English
with Chinese characters
<nigel> dsinger: they do - the situation is unclear re e.g.
mathematical symbols.
<nigel> glenn: need to clarify between font support and
terminal support
<nigel> dsinger: need to know that a document will work on a
specific terminal.
<nigel> pal: that document restriction is equivalent to a
processor recommendation.
<nigel> glenn: so this is a change in what needs to be
accomplished - it needs to be a processor constraint?
<nigel> pal: no, it's a document constraint that achieves the
same goal.
<nigel> glenn: to clarify, if I'm an author and use lang="en" I
should only stay within the Unicode code points that would
normally be rendered in English.
<nigel> r12a: that's not what I understood. I thought: if I'm a
user for English then I would expect minimal support for this
set of characters but could use any other characters, accepting
they may not appear correctly.
<nigel> pal: r12a states the processor requirement, glenn the
content requirement.
<nigel> r12a: so there's no limitation on what the author can
use, just a recommendation for a minimal set that must be
supported.
<nigel> dsinger: no it's the minimal set that can be expected
to be supported, so things outside that set might not render
properly.
<nigel> glenn: so does the CLDR define characters in those
terms?
<nigel> pal: are we comfortable with defining it as a document
constraint?
<nigel> nigel: is it per element?
<nigel> pal: it's the computed value for xml:lang for every
piece of content.
<nigel> glenn: I don't mind that, but don't want to define in
TTML
<nigel> pal: is there a fundamental reason not to have
recommendations at all?
<nigel> glenn: it's an unnecessary constraint because
practically people who author content in language have to use a
keyboard with an OS-determined code point set output
<nigel> pal: what about crazy symbols e.g. an aeroplane symbol?
People don't type that.
<nigel> r12a: CLDR defines the code point set per language.
<nigel> nigel: we need a proposal for some text
<nigel> pal: does dsinger want to draft some text that says
what he said?
<dsinger> In order to be confident that the text will be
correctly presented, text that is written in a given language
should use the code-points as defined in CLDR as required for
that language.
<nigel> group works on revised text...
<nigel> glenn: do you have any guidance about how this problem
has been handled before?
<nigel> r12a: not that I remember.
<nigel> glenn: is that because nobody thinks its a problem?
<nigel> r12a: if I understand you're working backwards from a
processor that assumes limited per-language capability, but
mostly we're not dealing with that situation but one where you
can define the font used, so it doesn't apply.
<nigel> dsinger: we're now in a market where web capability is
trickling into fixed capability devices like televisions.
<nigel> r12a: do you specify that e.g. televisions must support
some characters?
<nigel> glenn: we have content profiles and processor profiles
with different constraint logic. We have a formal mechanism to
define those profiles and IMSC is a set of content profiles.
<nigel> ... He's focussing on what must be/may be/must not be
in content.
<nigel> r12a: can you not specify a less restrictive processor?
<nigel> glenn: we were discussing earlier the mapping between
content and processor profile.
<nigel> ... We will define some default mapping.
<nigel> glenn: originally we only defined processor profiles
against features.
<nigel> nigel: can we not require that for restricted
processors the author must have access to a font with the
restricted set of code points?
<nigel> pal: that wouldn't permit profile-based
interoperability
<nigel> ACTION: pal to edit dsinger's proposed wording which
captures the intent. [recorded in
[57]http://www.w3.org/2013/11/15-tt-minutes.html#action05]
<trackbot> Created ACTION-243 - Edit dsinger's proposed wording
which captures the intent. [on Pierre-Anthony Lemieux - due
2013-11-22].
<nigel> nigel: is there anything we must avoid?
<nigel> r12a: my concern is a step removed - that we have
constrained processors. If that's the reality I can't find an
objection to the proposed wording.
<nigel> pal: * Point 2: what set of characters can we use?
<pal>
[58]https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/t
tml-ww-profiles.html
[58] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html
<nigel> pal: one issue is that there are no SE Asian language
sets so that's a deficiency that must be resolved. I've heard
CLDR so there's a Unicode effort to do this.
<nigel> ... Annex A is based on an analysis of subtitles not a
reference to e.g. CLDR.
<nigel> ... r12a pointed out that using reference automatically
includes future additions.
<nigel> ... There are some characters here that are included in
this list that aren't in CLDR generally. So my proposal is to
go through CLDR and compare this set with what's in CLDR and
generate the delta. Then build the table as CLDR + additions
e.g. box drawings.
<nigel> ... Then I plan to present the outcome to this group.
Until I go through that exercise I'm not sure what the outcome
will be.
<nigel> glenn: you need to be either exhaustive, i.e. per
country, to determine the delta, or you publish something
incomplete. There are no tables for many languages (lists some
fun ones) so you won't have time to complete this within the
charter period.
<nigel> ... So practically we'll have to publish incomplete
sets of tables based on the time available.
<nigel> pal: that's my expectation.
<nigel> glenn: is there a risk to this? What value is there in
attempting to do this huge job? What's the author's risk if
they use something not in the set. At worst a box on the
screen. If downloadable fonts are used maybe not.
<nigel> pal: there's the risk that some languages won't be
included. So r12a proposed separating this section into a note
that can be amended whenever new languages are analysed.
<nigel> glenn: I propose only including the deltas not all the
ligature entries. I'd also do it as a wiki-style registry that
allows easy editing.
<nigel> pal: It has to be more formal and be reviewed by the
group.
<nigel> nigel: that restricts the amendments to the charter
period.
<nigel> glenn: could also recommend to Unicode that they
publish subtitle sets.
<nigel> glenn: objects to anything that involves us publishing
character tables.
<nigel> pal: I'm not objecting to a note, but a wiki, because
wikis have no scrutiny.
<nigel> pal: This group should help with interoperability here.
<nigel> glenn: at this level I don't think its appropriate for
this group to do it. I don't mind referencing work by UTC in
this area. I've made the same objections in CSS when they tried
to define list counters in Ethiopian.
<nigel> ... the group doesn't have the resources to do this
sort of thing.
<nigel> r12a: the i18n group published that as a note.
<nigel> glenn: I wouldn't mind throwing it over to i18n.
<nigel> pal: it's in SDP-US
<nigel> glenn: I wouldn't mind it as a processor profile.
<nigel> pal: but it's the same.
<nigel> glenn: if you could specify for just US I might not
object.
<nigel> pal: what's the risk?
<nigel> glenn: this group doesn't have the expertise. I don't
see us as a repository for all regions coming to us. It'll
never be complete and always be wrong.
<nigel> glenn: this position is based on past experience.
<nigel> nigel: is there an acceptable proposal?
<nigel> glenn: would accept it if i18n took it on and we could
reference. Or if we could relate to CLDR. Or having a small
table that's specifically for 608 and 708 reasons, and if EBU
or other countries want to provide specific regional
requirements
<nigel> ... beyond the normal set then I might be able to
accept that.
<nigel> pal: but this is that.
<nigel> glenn: the difference is who comes to whom.
<nigel> pal: this is based on actual subtitle practice, so why
wouldn't we accept it?
<nigel> glenn: I have a lot of experience watching how Unicode
attempted to encode countries' languages without their
participation and it caused lots of problems. Eventually the
countries went to Unicode.
<nigel> pal: I would accept removing this section.
<nigel> glenn: can we give it to the i18n group to document -
it's not specific to captioning.
<nigel> pal: this is an important scope issue - it's
specifically for subtitling and captioning.
<nigel> r12a: the i18n group wouldn't have the expertise needed
to define the additional characters needed for capturing.
<nigel> glenn: if it's just the deltas I'd like to see it on a
case by case basis.
<nigel> ... It's hard to argue in the general sense.
<nigel> pal: my proposal is to generate the delta and we can
have a look at it then.
<nigel> glenn: I'll withdraw my pre-emptive objection and allow
this work to proceed.
<nigel> ACTION: pal to proceed with work to investigate deltas.
If time doesn't allow the fallback is to remove annex A.
[recorded in
[59]http://www.w3.org/2013/11/15-tt-minutes.html#action06]
<trackbot> Created ACTION-244 - Proceed with work to
investigate deltas. if time doesn't allow the fallback is to
remove annex a. [on Pierre-Anthony Lemieux - due 2013-11-22].
<nigel> pal: propose to remove annex B
<nigel> issue-295: see action-244 and action-243.
<trackbot> Notes added to issue-295 Remove code point
restrictions from IMSC.
<r12a>
[60]http://rishida.net/utils/subtags/index.php?check=zh-cmn-Han
t&submit=Check
[60] http://rishida.net/utils/subtags/index.php?check=zh-cmn-Hant&submit=Check
<nigel> r12a: this is a reference to the correct way to
identify language subtags
<nigel> r12a: note spelling error in the word Finnish in Annex
A.
<nigel> pal: the input document is from an industry standard.
<nigel> ... (not written by me!)
<nigel> issue-188?
<trackbot> issue-188 -- Bounding TTML (was: SDP-US) rendering
complexity -- open
<trackbot>
[61]http://www.w3.org/AudioVideo/TT/tracker/issues/188
[61] http://www.w3.org/AudioVideo/TT/tracker/issues/188
<nigel> pal: feedback on the Hypothetical Render Model is
needed at this point.
<nigel> pal: this issue was a proposal to limit complexity in
SDP-US. There is now that proposal, in IMSC, so I'm happy to
close.
<nigel> pal: the parameters in CFF-TT were deliberately chosen
to be sufficient for SDP-US so this is covered in IMSC.
<nigel> pal: this is specifically related to SDP-US, which has
been published. How does the group wish to deal with it?
<nigel> glenn: we have some potential maintenance to do.
There's no reason not to implement errata. Adding this would be
a step further than that. I wouldn't want to cut and paste IMSC
HRM into SDP-US.
<nigel> ... We could always add a note and an informative
reference, as a clarifying errata.
<nigel> glenn: does either SDP-US or IMSC support the set
animation element?
<nigel> pal: yes
<nigel> glenn: but there are no different deltas within an
intermediate synchronic document?
<nigel> pal: yes, it's event based.
<nigel> glenn: ISDs are now defined not to contain any set
transitions. With animate that will change.
<nigel> pal: I expect IMSC not to support animate so the
functionality would have to be expressed in terms of a sequence
of sets.
<nigel> glenn: we specified in TTML 1 that a processor may
interpolate between ISDs.
<nigel> nigel: If we add complexity constraints do we need to
ensure that FCC required minimum performance, i.e. derived from
CEA-608 and 708, are met?
<nigel> pal: That exercise was done by DECE. They are satisfied
that the performance parameters in the HRM today meet those
requirements.
<nigel> pal: I propose re this issue to defer it to the
maintenance of SDP-US and revisit it then.
<nigel> no objections
<nigel> issue-188 updated
<nigel> issue-201?
<trackbot> issue-201 -- How to specify aspect ratio to
understand positioning that may apply for display or video. --
open
<trackbot>
[62]http://www.w3.org/AudioVideo/TT/tracker/issues/201
[62] http://www.w3.org/AudioVideo/TT/tracker/issues/201
<nigel> pal: discussion on Monday re definition of pixels now
dependent on glenn to give further consideration.
<nigel> ... Mapping of the root container to video is
application dependent, in general, so should not be defined in
TTML, but perhaps adding an aspect ratio metadata element to
TTML indicating what was the aspect ratio of the video at
authoring.
<nigel> nigel: that's done in EBU-TT-D too.
<nigel> glenn: we already have this in SMPTE-TT-11 with the
m708:aspectRatio, whose intent is to communicate the aspect
ratio of the related video at authoring.
<nigel> ... my thinking was to introduce a ttp: or ttm: element
or attribute.
<nigel> nigel: I think it's ttm:
<nigel> glenn: we use ttp: for metadata that affects
processing.
<nigel> nigel: it's not for processing.
<nigel> pal: IMSC might use it for processing. Is that bad?
<nigel> nigel: it's bad.
<nigel> pal: this is a response trying to address the long
discussion we had previously. IMSC could just create an
extension attribute and define it.
<nigel> ... Another option is to define in TTML 2 an attribute
that's aspectRatio, and allow profiles to specify processor
behaviour.
<nigel> glenn: We could put something into the spec early to
satisfy the authorial intention requirement, using ttm: and
think more on this and maybe come up with a more formal way of
affecting processor,
<nigel> ... e.g. drawing from SVG viewbox semantics and mapping
the viewport to the device coordinate space. As we proceed with
that we might have some ttp: parameters that affect processor
behaviour.
<nigel> ... I'm just thinking about this.
<nigel> pal: we need to take into account that as soon as we
define it people will use it.
<nigel> glenn: I want to make sure the first thing we define
carries little processing impact.
<nigel> nigel: as ebu-tt-d already has it this would be a good
thing to add, for profile convergence.
<nigel> glenn: if we put something in ttm: space early it gives
us the ability to support the current definition in SMPTE-TT as
well as EBU-TT to satisfy the immediate need.
<nigel> nigel: all accept this working proposal, subject to
potential revision?
<nigel> nobody objects
<nigel> glenn: if we do that we'll have to put some large
warning labels on it saying 'not for processing. We expect to
introduce processing-related parameters soon'
<nigel> pal: IMSC does specify processing behaviour based on an
aspect ratio parameter.
<nigel> issue-201: Glenn to investigate SVG viewbox etc and see
if something can be brought in from that space.
<trackbot> Notes added to issue-201 How to specify aspect ratio
to understand positioning that may apply for display or video..
<nigel> nigel: there are also uses for bar support and other
aspect ratio parameters.
wrap-up
<nigel> nigel describes what we did, from the agenda.
<nigel> mark_vickers: We received a Consensus Input from the
Web and TV IG.
<nigel> nigel: we also received a liaison from EBU which we
didn't cover on the agenda.
<nigel> nigel: next meeting Thursday
<nigel> glenn: regrets until Dec 5th.
<nigel> nigel: thanks everyone.
<nigel> meeting closes.
Summary of Action Items
[NEW] ACTION: dsinger to consider the problem of the license
change from CG to WG, with the AC and AB and staff [recorded in
[63]http://www.w3.org/2013/11/15-tt-minutes.html#action03]
[NEW] ACTION: pal to edit dsinger's proposed wording which
captures the intent. [recorded in
[64]http://www.w3.org/2013/11/15-tt-minutes.html#action05]
[NEW] ACTION: pal to proceed with work to investigate deltas.
If time doesn't allow the fallback is to remove annex A.
[recorded in
[65]http://www.w3.org/2013/11/15-tt-minutes.html#action06]
[NEW] ACTION: pal to raise this issue [recorded in
[66]http://www.w3.org/2013/11/15-tt-minutes.html#action01]
[NEW] ACTION: plh to edit charter by next tuesday [recorded in
[67]http://www.w3.org/2013/11/15-tt-minutes.html#action04]
[NEW] ACTION: silvia to add keywords to bugs in tracker
[recorded in
[68]http://www.w3.org/2013/11/15-tt-minutes.html#action02]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [69]scribe.perl version
1.138 ([70]CVS log)
$Date: 2013-11-15 09:30:24 $
__________________________________________________________
[69] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[70] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [71]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[71] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/poit/point/
Succeeded: s/thje isdue/the issue/
Succeeded: s/questionalble/questionable/
Succeeded: s/MS did object/IE team was uncomfortable with it for some ti
me before implementing it/
Succeeded: s/FORMS/foms/
Succeeded: s/indy UI/Indie UI/
Succeeded: s/ti,e/time/
FAILED: s/@@@/Kawamori/
Succeeded: s/back//
Succeeded: s/with/wish/
Succeeded: s/mark/mark_vickers/
Succeeded: s/IG-EVA/FG AVA/
Succeeded: s/page/charter/
WARNING: No scribe lines found matching ScribeNick pattern: <silvia> ...
Found ScribeNick: olivier
Found ScribeNick: nigel
Found Scribe: silvia
Inferring ScribeNick: silvia
ScribeNicks: olivier, nigel, silvia
WARNING: Replacing list of attendees.
Old list: +1.617.766.aaaa Ralph Taishan mijordan
New list: Taishan +1.617.766.aaaa mijordan
Default Present: Taishan, +1.617.766.aaaa, mijordan
Present: (BBC) (Opera) Giuseppe Glenn Ishida Israel Kepeng_Li Mark Nigel
Olivier Pascale Pierre_Anthony Richard Sylvia Thereaux Thierry Vickers
Found Date: 15 Nov 2013
Guessing minutes URL: [72]http://www.w3.org/2013/11/15-tt-minutes.html
People with action items: dsinger pal plh silvia
[72] http://www.w3.org/2013/11/15-tt-minutes.html
WARNING: Possible internal error: join/leave lines remaining:
<mark_vickers> mark_vickers_vickers has joined #tt
WARNING: Possible internal error: join/leave lines remaining:
<mark_vickers> mark_vickers_vickers has joined #tt
End of [73]scribe.perl diagnostic output]
[73] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 21 November 2013 16:30:10 UTC