See also: IRC log
<trackbot> Date: 21 August 2014
<scribe> scribeNick: nigel
group: no AOBs to raise
mike: regrets for me for Sep 4 meeting
nigel: Let's set aside 1 hour for our 4th September meeting
RESOLUTION: We will proceed with the Geneva F2F meeting as planned.
pal: Based on the attendees I suggest we take 2-3 hours on day 2 morning to resolve any issues on IMSC 1 in prep for LC.
nigel: We have more folk interested in VTT attending on day 1 than on day 2 so that makes sense to me.
pal: I may have to duck out on 2nd day afternoon for some SMPTE stuff.
mike: I plan to try to be there both days. On day 2 at 1700 local time there's a meeting I need to be at but we should have finished by then.
nigel: Anything else to squeeze into the agenda as well as the TTML <--> WebVTT and IMSC 1 work?
group: nothing to add.
nigel: We need to think about the
structure of the TTML <--> WebVTT part - I've added some
thoughts, but please could all consider this and make any
proposals first on the reflector, and then we can
... make them more concrete on the wiki page.
frans_EBU: We're okay to use the EBU canteen on an ad hoc basis - it won't be a served meal.
nigel: So the only cost for attendance is food at EBU, travel and accommodation - there's no other attendance fee.
action-319?
<trackbot> action-319 -- Nigel Megitt to Draft liaisons to relevant organisations for imsc 1 timeline -- due 2014-08-21 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/319
mike: Both SMPTE and DECE messages were transmitted. Response will probably be after the Geneva meeting.
frans_EBU: I can confirm I received the EBU message and will forward it today.
close action-319
<trackbot> Closed action-319.
action-323?
<trackbot> action-323 -- Nigel Megitt to Update issue-263 to target product ttml2 and open a new one on sdp-us. -- due 2014-08-21 -- PENDINGREVIEW
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/323
nigel: I completed this.
close action-323
<trackbot> Closed action-323.
action-320?
<trackbot> action-320 -- Glenn Adams to Review https://www.w3.org/wiki/ttml/codecsregistry w.r.t. recent ttml2 changes in profile definition mechanisms -- due 2014-08-21 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/320
action-322?
<trackbot> action-322 -- Jerry Smith to Indicate preference for updating sdp-us for ttml2 -- due 2014-08-21 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/322
jdsmith: Still working on that one. Hopefully will do so in the next few days.
action-324?
<trackbot> action-324 -- Glenn Adams to Draft a note for imsc 1 progressivelydecodable to make concrete what authors should take into account -- due 2014-08-21 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/324
glenn: My email earlier was related to this.
pal: We agreed that within <head> it is not required to dereference forward references while parsing?
glenn: That's correct.
... The dereferencing process only occurs during the synchronic
flow processing process as currently defined, generally done
after the whole document has been processed.
... It could be done as an optimisation during processing of
the <body> but elements spread out throughout the whole
document may select into the same region;
... If they're ordered temporally then you would be able to
perform the synchronic processing once you get to a time you
know is later than the time of the elements
... currently being considered for inclusion in the synchronic
document.
... So the only consideration is times.
... My message earlier today related to the styles portion.
There doesn't seem to be an ordering dependency there.
pal: If you order the style elements in order in <head> you don't have to wait until the end of <head> to compute your final style properties.
glenn: You never do that until you process the content elements, and that doesn't occur until you perform the synchronic processing step.
pal: So if style id="a" references style id="b" then I need to see both, for a parsing simplicity aspect.
glenn: That's an optimisation but not predicated by anything in the spec. It doesn't matter if they're ordered or not; the optimisation may not be possible if they're not ordered.
pal: The purpose of the flag is to indicate that the optimisation is possible.
glenn: In that case it should be named "pre-optimised" or something.
pal: yes, it's a head optimisation thing.
glenn: It's a small optimisation.
pal: I agree with this assessment. It's called progressivelyDecodable in CFF-TT but if there's a consensus on a different name we could consider that.
glenn: We should keep the name but have a note that points out what I said about styles.
pal: I'm happy to have that note. Is that all of the note or would there be other stuff?
glenn: That's all I'd comment on.
pal: You can move the action to me then. The note will indicate that the ordering of style in head is not necessary for progressive presentation but is an optimisation of the head element.
glenn: There are only 2 types of
forward referencing: 1. Chained styles with xml:id; 2. Temporal
ordering of elements. Then I'd explain that dereferencing style
elements is technically only required after <head> is
fully parsed.
... In the case of a non-linear ordering it might prevent an
optimisation prior to completing parsing of the head
element.
nigel: I've reassigned that action to pierre.
pal: Just to confirm, the only xml:id referencing that impacts ordering is the style one - is that your conclusion?
glenn: Yes, in TTML1. Region is
the other thing that makes references, but only from body
elements to region elements in the head, so the definition
always precedes the usage.
... TTML2 will be a little more complicated due to out of line
animation plus potential link elements.
mike: The assumption in DECE has always been that it's after the parsing of head that we need to worry about most.
issue-334?
<trackbot> issue-334 -- Misuse of style property characteristics with ttp:progressivelyDecodable -- pending review
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/334
pal: this needs review by Glenn.
glenn: sounds good, we can close this.
close issue-334
<trackbot> Closed issue-334.
glenn: Is progressivelyDecodable a parameter or a metadata attribute?
pal: It's ittp:
glenn: It's sort of borderline between parameter and metadata. It's potentially usable by a processor so I can accept it's a parameter.
mike: Agree - it changes the decoding approach for the processor.
Issue-303?
<trackbot> Issue-303 -- Permit HTML-style <a> elements to contain href links -- open
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/303
nigel: This has only been discussed in relation to the WAI/PF Media Accessibility Requirements, which in the Enhanced Captions requirements state that a link mechanism should be included.
glenn: I'm working on a more
generic mechanism for expressing links and ruby rather than
opening it up for everything.
... I'm thinking about adding an attribute to <span>
which may work a bit like the class attribute, with a string of
one or more tokens, that adds semantics onto span
... such as 'this is a ruby span', 'this is an anchor/link
span' etc. It turns out that Apple has added support for ruby
in TTML using a ruby token to span
... It seems to me that the same approach could be applied to
link. Just thinking about that.
Courtney: I want to clarify: we
have a proposal for doing it that way for the iTunes Timed Text
Format, derived from TTML. We did that
... because the ruby tag isn't in TTML. There are benefits to
using it as a ruby tag - we'd have consistency with other
specs.
... If we could add the ruby tag into TTML2 then I think Apple
would use that instead.
glenn: This could be a useful
side-discussion at the F2F. We already have a relatively
complex process for translating
... from TTML into HTML so it wouldn't be difficult to
translate from a marked up span to the equivalent HTML.
... From a specification and schema perspective it's easier not
to define new element types, but I'm willing to consider both
approaches.
... I actually like the way you did it - it integrates pretty
well and has other benefits.
Courtney: Okay, it would be good to get a decision one way or the other.
nigel: I suggest this should be on the agenda for TPAC
glenn: Yes it's an issue to resolve before LC at least.
issue-310?
<trackbot> issue-310 -- Forward reference rule doesn't take into account child elements -- pending review
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/310
pal: I've addressed your last comment on the reflector.
close issue-310
<trackbot> Closed issue-310.
issue-335?
<trackbot> issue-335 -- In order to handle offsets between start time in TTML docs and start time in video, allow negative times to be used in fragment begin times. -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/335
reopen issue-335
<trackbot> Re-opened issue-335.
nigel: The reflector discussion seemed to end up that by adding a document temporal offset we can make whole document adjustments most easily.
Courtney: This may be specific to our workflow.
glenn: When we drafted the timing
section I drafted a referenceBegin parameter, but at that time
we didn't have a strong driving use case.
... Now that we have this use from Apple for negative times it
would resolve that. It might also be used to make it simpler
for SMPTE-TT documents that
... start at 10:00:00 to change the tokens to zero based
times.
nigel: As I understand it transformations on times are not permitted on smpte times with discontinuous markerMode - would that change that?
glenn: I'd have to have a look at that more closely.
issue-336?
<trackbot> issue-336 -- Syntax definition missing from ittp:aspectRatio -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/336
reopen issue-336
<trackbot> Re-opened issue-336.
pal: That's something I noticed - we need to make a change to ttp:aspectRatio along the lines of what we had to do for progressivelyDecodable.
issue-337?
<trackbot> issue-337 -- Update SDP-US for TTML2 -- raised
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/337
reopen issue-337
<trackbot> Re-opened issue-337.
pal: A number of the remaining
open issues are related to the change proposal on profiles. The
proposal is to refactor IMSC to add another profile, but
... that's contingent on some not-yet-completed submissions. So
we can't really make progress on any of these.
... I need to wait for all the requests to be in by Sep 5
before I can make an editorial proposal. It's not clear how
e.g. #cellResolution will interact with other feature
requests.
issue-327?
<trackbot> issue-327 -- IMSC should meet W3C QA Framework Spec guidelines -- open
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/327
pal: My plan is to complete the
bulk of changes and then do an editorial pass on the whole
document, so I expect to register that issue at the last
moment.
... Unless you know of specific normative impact then it's only
editorial.
group: no specific CPs to discuss.
nigel: Meeting adjourned - thanks everyone, reminder there's no meeting next week.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I'm happy/I can accept/ Succeeded: s/sorry for being late (I am +41..)// Succeeded: s/both day/both days/ Found ScribeNick: nigel Inferring Scribes: nigel Default Present: Mike, nigel, pal, courtney, jdsmith, glenn, +41.22.717.aaaa, Frans_EBU Present: Mike nigel Pierre Courtney jdsmith Frans_EBU Regrets: Andreas_Tai Found Date: 21 Aug 2014 Guessing minutes URL: http://www.w3.org/2014/08/21-tt-minutes.html People with action items:[End of scribe.perl diagnostic output]