Timed Text Working Group Teleconference

10 Jan 2018


Andreas, Chris, Tess


Cyril: We need to tell authors to use type parameters available in the mime type in preference
... to the format attribute. Then the question is if we should define some tokens, like SDR
... or HDR.

Glenn: Yes we should.

Chris: I don't think we expect SDR or HDR to be in a MIME type.

Cyril: Can we use media queries in format?

Nigel: No they should be in the condition attribute. I agree that SDR vs HDR does seem to
... be more of a media query issue though than format.
... Unless we have a concrete use case for removing format - if SDR and HDR are media queries then we have no others.

Glenn: It's already interoperably implemented for font format.

Cyril: This is about <image-format>

David: I think we should remove image-format too - it is underspecified to the point that
... it is not useful. Alternatively tighten it up.

Glenn: It would be asymmetrical to leave it on audio, font and data but remove it from image.

<dsinger> we should raise an issue that we should use MIME types for fonts as well https://www.iana.org/assignments/media-types/media-types.xhtml#font

Nigel: I have raised #542 for removing `<image-format>`
... And #543 for removing `<font-format>`.

github-bot, end topic

Andreas: [need to drop off the call]

Support for roll-up and paint-on captions. ttml2#443

github: https://github.com/w3c/ttml2/issues/443

Nigel: We need to write a disposition message to send back to the commenter.
... I'll draft something for review by the group.

SUMMARY: Nigel to draft a disposition message

github-bot, end topic

SMPTE backgroundImage annotation ttml2#460

github: https://github.com/w3c/ttml2/issues/460

SUMMARY: Nigel to include information about the change made here in any draft future message to SMPTE.

github-bot, end topic

Definition of [external data resource] does not include src attribute on image element. ttml2#436

Nigel: Could we rename "Embedded Content" to "Resource Content"?

Pierre: This is an editorial change just to make it clearer for other people.

Glenn: I don't like that.

Chris: "Extrinsic Content"? Since it is all non-TTML.

Glenn: It would be a lot of work to make this change.
... [also didn't like Media Content]

Pierre: It's up to the group.

Nigel: Seems to me that we all agree it's not a great name right now but do not care enough
... to make a change.

RESOLUTION: We will not make a change here because we have insufficient willingness to find and implement a different name.

github-bot, end topic

github: https://github.com/w3c/ttml2/issues/436

RESOLUTION: We will not make a change here because we have insufficient willingness to find and implement a different name.

github-bot, end topic

trackbot, this is ttml

<trackbot> Sorry, nigel, I don't understand 'trackbot, this is ttml'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

trackbot, start meeting

Date: 09 January 2018

Feedback on HDR compositing ttml2#400

github: https://github.com/w3c/ttml2/issues/400

Pierre: I've reviewed the comment and believe it is a misunderstanding.
... The commenter believes that tts:luminanceGain="1" yields a linear light output of 10000 nits
... when in fact it yields a peak output of 80 nits.

Nigel: I sent an email to the commenter drawing his attention to your comments.
... Please could you draft a formal response?

Pierre: Yes absolutely.
... The commenter proposes an example but there is already one and I don't believe
... another would be helpful. The current example is more helpful for web applications.

RESOLUTION: No change is necessary.
... Since we do not agree with the issue, mark as WR-Rejected.

github-bot, end topic

Security and privacy re external resources ttml2#403

github: https://github.com/w3c/ttml2/issues/403

Glenn: I plan to do what this issue requests.

RESOLUTION: WG agrees to implement the issue as requested.

github-bot, end topic

Reference CORS, Fetch etc ttml2#404

Glenn: I plan to do this.

RESOLUTION: WG agrees to add this as requested, subject to Editor input

github-bot, end topic

Aspect ratios when SAR specified, but DAR and PAR not specified. ttml2#539

github: https://github.com/w3c/ttml2/issues/539

Cyril: Yesterday we reviewed with Pierre and Glenn the discrepancies between
... ittp:aspectRatio and ttp:displayAspectRatio and there were two cases where the text
... was not aligned, which is this issue.

Glenn: There's now a PR open on this.

github-bot, end topic

Add ttm:alt metadata attribute item. ttml2#490

github: https://github.com/w3c/ttml2/issues/490

group: Discusses this and agrees it.

Glenn: I'll update the pull request.

RESOLUTION: Do https://github.com/w3c/ttml2/issues/490#issuecomment-356123618

github-bot, end topic

Require support for DFXP transformation and presentation profiles. ttml2#364

github: https://github.com/w3c/ttml2/issues/364

Nigel: I'm confused - there's already a note in G.2 and G.3 saying that the TTML2 profiles
... are supersets of DFXP.

Glenn: What's different is that it didn't require support for the DFXP profile designators.

Nigel: Ah, thank you, makes sense.

github-bot, end topic

Is ttp:version="2" required if ttp:contentProfiles is present? ttml2#435

github: https://github.com/w3c/ttml2/issues/435

Cyril: We discussed this yesterday. It's a long standing issue. Glenn came up with a list of
... cases where ttp:profile is used, one is to determine the default processor profile when
... there is no other information and the other is to select the validation schema.

Glenn: [points to comment describing agreement from yesterday]

Nigel: Would you please add a column to the table in E.2 specifying the "version introduced"
... to support the heuristic bullet about inferring the spec version from the most recently defined required feature?

Glenn: Yes, that's a good idea.

Nigel: Regarding the bullet about defining new feature designators to drive selection of alternate algorithm behaviour,
... if the only case where that applies is root inheritance then I would rather remove root
... inheritance.

Pierre: Yes

Cyril: That works for me.

Glenn: I could support that as I don't know of anyone using that.
... I created #546 for root inheritance removal.

Nigel: What are the other alternate algorithms?

Glenn: position and origin handling especially if neither is present, because they have different initial values.

Pierre: Another is the semantics of offset time and fractions component in smpte timebase.
... In those cases I don't know why they are tied to ttp:version. In TTML1 we said "should not be used"
... If we don't want people to use them we should just deprecate them.

Glenn: We did and conditionalised how the deprecation was handled. But I agree.

RESOLUTION: Adopt https://github.com/w3c/ttml2/issues/435#issuecomment-356142844

github-bot, end topic

Definition of tts:fillLineGap does not match itts:fillLineGap as specified in IMSC 1.0.1. ttml2#429

github: https://github.com/w3c/ttml2/issues/429

Cyril: We've discussed this today and agreed to remove `tts:fillLineGap`

RESOLUTION: Following further discussion, group confirms that tts:fillLineGap is to be removed.

github-bot, end topic

Definition of ttp:activeArea does not match ittp:activeArea defined in IMSC1.0.1. ttml2#428

github: https://github.com/w3c/ttml2/issues/428

RESOLUTION: Following further discussion, group confirms that ttp:activeArea is to be removed.

github-bot, end topic

Deprecate use of pixel units unless tts:extent on root element is in pixels. ttml2#330

github: https://github.com/w3c/ttml2/issues/330

Glenn: Everyone agrees with this, I just want to get confirmation.
... This will probably cause more deprecation warnings than anything other deprecation we are making.

Nigel: How do you deprecate the absence of something?

Pierre: Require issuing a warning if pixel units are used but no tts:extent is present on tt.

Nigel: Where in the spec?

Cyril: On the `<length>` unit definition.

Pierre: And on tts:extent.
... Or on tt?
... I'm happy either way.

Glenn: Probably on the tt element.

Nigel: Can we please also have a note on the `<length>` unit to warn about this behaviour?

Glenn: Sure that's reasonable.

RESOLUTION: Implement this as per the above discussion.

github-bot, end topic

LWSP in rgba expressions? ttml2#315

github: https://github.com/w3c/ttml2/issues/315

Cyril: I'll create an issue for TTML1 for the equivalent of this, in color.
... It's w3c/ttml1#322.

Nigel: When you say "allow lwsp everywhere", what exactly is "everywhere"? Is it all tta, ttp and tts attributes?

Glenn: Pretty much, yes. I'm not proposing to allow lwsp between value names and ( for example.

Chris: That matches what is in CSS too.

Glenn: I should change `<color>` to combine the `"rgb" "("` into `"rgb("` and `"rgba" "("` into `"rgba("`

Nigel: In `<number>`, `<non-negative-number>` and `<percentage>` there shouldn't be any lwsp allowed.

Chris: Implementers prefer no space between a number and %.

Nigel: So that applies between number and pitch-units in `<pitch>` too.

Chris: Yes

Cyril: It may be clearer and easier to put `<lwsp>` explicitly everywhere it is allowed.
... We should do that.

Glenn: I may have to accept that.

Nigel: `<position>` already does it.

Glenn: `<condition>` does too.
... There are some animation value expressions too that need it.

RESOLUTION: Specify explicitly where lwsp is permitted.

github-bot, end topic

Should rubyOverhang:allow overlap ideographs in Japanese? ttml2#260

github: https://github.com/w3c/ttml2/issues/260

RESOLUTION: Remove rubyOverhang as per the pull request and seek confirmation from @r12a that it addresses his comment.

github-bot, end topic

Mismatch between CSS and TTML2 text align styling on <span> ttml2#238

github: https://github.com/w3c/ttml2/issues/238

Glenn: If we take out ipd and bpd by marking them as at risk then we won't be able to
... meet the SMPTE digital cinema request for "struts".

Pierre: If they have people who want to implement then we will not need to remove it.

Nigel: Is there any other use of inline-block?

Cyril: Yes, that's the only other use.

Glenn: ipd and bpd are also needed for image sizing.

Pierre: We should add inline-block to the set of at risk features if we add ipd and bpd.

RESOLUTION: WG is disposed to remove applicability of tts:textAlign to span and mark bpd, ipd and inline-block as "at risk" in the CR.

github-bot, end topic

Link from tts:direction to tts:writing-mode ttml2#264

github: https://github.com/w3c/ttml2/issues/264

Cyril: We discussed this yesterday. direction has three usages:
... 1. When there is direction and unicodeBidi it tells you which embedder marker you should put.
... 2. When direction is at the p level it sets the paragraph embedding level.
... 3. It's computed value is taken from writingMode.
... The proposal for addressing this comment is not to describe the behaviour but to link
... from direction to unicodeBidi and the special semantics section. I would consider that
... purely editorial.
... I will propose a pull request for this and include the explanatory note that @r12a requested.

RESOLUTION: Add the links and explanations that @r12a requested.

github-bot, end topic

Styling using tts:direction: there should be an `auto` value ttml2#268

github: https://github.com/w3c/ttml2/issues/268

Cyril: I think we can mark this as commenter no response.

RESOLUTION: Group considers the window for a response to be closed and to close the issue.

github-bot, end topic

Meaning of 'glyph area descendant' ttml2#236

github: https://github.com/w3c/ttml2/issues/236

Nigel: On reviewing this, it appears that there is work to do.

Glenn: I missed that - I will tag it for my priority.

github-bot, end topic

Pierre: When we discussed this in the context of the slightly different w3c/ttml1#251 the
... consensus was that unrecognised elements and attributes are pruned prior to validation
... processing.
... I now think that the wording in w3c/imsc#216 is incorrect since it states that foreign
... namespace elements are not permitted everywhere, but we discussed this morning that
... they are actually pruned prior to validation processing, which means they are permitted.
... We need to reopen w3c/imsc#213 and say that the conclusion is that foreign namespace
... elements are in fact permitted.

Nigel: In IMSC we could impose the rules stated even if they are more specific than what
... TTML says.
... I've reopened it.

Meeting adjournment

Nigel: Thanks everyone for a long and productive day. Reconvene 0830 tomorrow PST. [adjourns meeting]

<scribe> Chair: Nigel, David

<scribe> Chair: Nigel

<trackbot> Meeting: Timed Text Working Group Teleconference

<trackbot> Date: 10 January 2018


Day 2

Nigel: Yesterday we managed to cover all the agenda marked issues for IMSC 1.1 and
... TTML1, so we have a free run at TTML2 issues this morning, then after lunch we will
... do a quick status review of the remaining TTML1, TTML2 and IMSC issues.

Cyril: Yesterday we dealt with 46 issues across all specs.
... 9 on TTML1, 7 on IMSC and 30 on TTML2.

Nigel: Are there any other things we need to cover today?

Cyril: No but we may need some time in the afternoon to cover more TTML2 issues if possible.

TTML2 Editing

<scribe> scribe: nigel

Nigel: Last year Pierre was able to take on the role of Editor for TTML1 in addition to Glenn.
... I made the point that in general it is good to have more than one editor per spec.
... Following discussions I would like to invite Cyril to become an Editor of TTML2 again
... alongside Glenn.

Cyril: Sure.

Nigel: Thank you!
... I will open an issue on the spec to add your name.

Appendix N assumption that root temporal extent corresponds with the beginning of a related media object ttml2#76

github: https://github.com/w3c/ttml2/issues/76

Glenn: We already decided not to include mediaOffset.

Nigel: Yes, also mediaDuration.

Glenn: pull #536 does that.

Nigel: I recall from TPAC that we agreed to remove mediaDuration alongside mediaOffset
... as a pair.

Glenn: I don't recall that and would like to consider it in a separate issue.
... Media Duration is needed to resolve indefinite end times.

Nigel: At TPAC we agreed that the clipEnd semantics could be used for that place instead.

Cyril: The pull request doesn't mention the issue.

Glenn: I restored the TTML1 text saying that an offset may be needed if the assumption
... does not hold that the origin of media time corresponds to the begin time of a related media offset.

Nigel: This text has a problem in that it is only a subset of the full set of assumptions.
... In fact the assumption more broadly is that the origin of the media time coordinates is
... the same as the origin coordinates of the document instance.
... I think I need to file an issue for this point.

Pierre: If we have disagreement over the informative text then the pragmatic approach is
... to remove the text.

Glenn: We don't use the word origin or formally define epoch.

Nigel: I've raised #549 for removing mediaDuration.
... And #550 about the media offset note.

SUMMARY: Resolve pull #486 and remove mediaOffset and mediaDuration.

Add parameters to define the temporal extent ttml2#483

github: https://github.com/w3c/ttml2/issues/483

Nigel: Reviewing the pull request for this, #486

Pierre: If this were metadata I would have no problem with it.

Glenn: I'm not convinced that it needs to be a parameter.

Nigel: [on whiteboard, explains use/requirement]

Glenn: It is possible to generate ISDs that only have metadata in them.
... I'm not convinced that this is needed.

Cyril: clipBegin and clipEnd have different definitions in SMIL

Nigel: I hadn't noticed that they are in SMIL - I would certainly change the name in that case.
... Thank you for pointing that out.

Pierre: I object to changing the processing model.

Cyril: Does this proposal generate any changes to timing, like offsets?

Nigel: No, it does not modify the relative timings, it just defines those parts of the timeline
... that should be presented.

Cyril: That removes one possible problem I was concerned about.

Glenn: I agree with Pierre on not changing the processing model.

Nigel: Note that ISD generation is conceptual only in TTML1 and no processor needs to
... generate ISDs at all. The serialised format for ISDs is introduced in TTML2.

Cyril: It looks like you have a use case Nigel (is that a BBC or an EBU thing?).

Pierre: I don't want this to change the processing model.

Nigel: What about if its behind a feature?

Pierre: Makes no difference.

Nigel: To answer the BBC/EBU question: this is not a formal request from EBU. It is something
... that I have observed would be useful for EBU-TT Live and if made available I would
... propose back to EBU that it is used in EBU-TT Live.

Cyril: How urgent is this?
... Would you be able to defer it?

Andreas: At the moment there is no communication from EBU about adoption of TTML2.
... We are pretty close to concluding on TTML2 and there is no request, so I'm not sure how
... strongly we should go for that.

Nigel: I would rather not put this in if it is metadata - I believe it is parameter data.

Glenn: If it is in then we have to have it everywhere in TTML.

Cyril: Can we resolve to defer it?

Pierre: Or put it in a "live" module?

Nigel: [considers this] By omitting this then we retain the much discussed state where the
... root temporal extent is to some degree ambiguous or unclear, whereas including this
... defines it concretely.
... Since we have no consensus on this I'm closing the pull request.

RESOLUTION: Do not apply this change to TTML2, consider using in a future spec version or module.

github-bot, end topic

Begin times being relative to the root temporal extent can be wrong. #512

github: https://github.com/w3c/ttml2/issues/512

Nigel: [reiterates issue] Look at e.g. isd:isd which says:
... This begin time is expressed as an offset from the begin time of the root temporal extent of the source TTML document from which this isd:isd element was derived.
... But it is somewhat unclear when the root temporal extent begins, and it appears from the
... definition that it may not always begin at zero.

Glenn: What is the minimum change we can make to satisfy you Nigel?

Nigel: I haven't sized all the possible resolutions, but I would say we need to explain that
... ISD begin times and other general begin times are related to the origin of the time
... coordinate system.

Glenn: If you want to propose a note against the Root Temporal Extent definition to discuss
... the zero point and time coordinates, and any minimal changes to e.g. isd:isd, then we
... can look at that offline.

Nigel: okay I'll do that.

SUMMARY: Nigel to propose a first draft of changes to address this.

github-bot, end topic

Remove ttp:mediaDuration. ttml2#549

github: https://github.com/w3c/ttml2/issues/549

Glenn: If the processor does not know what duration to use then indefinite durations could
... not be resolved to a finite interval. I see the comment that ISD can now have an indefinite
... end time. I'm willing to go with removal at this point.

RESOLUTION: Remove ttp:mediaDuration

github-bot, end topic

Add @ttm:alt as shorthand for ttm:item name="altText" (#490). ttml2#506

Nigel: Since we resolved not to add @ttm:alt we should close this pull request.

RESOLUTION: Close without merging.

Clarify/summarize use of foreign namespace elements and attributes. ttml2#387

github: https://github.com/w3c/ttml2/issues/387

Pierre: The conclusion at this point, as captured yesterday, is that all foreign namespace
... elements and attributes are allowed everywhere, and we reopened the IMSC issue yesterday.
... One potential outcome here is to clarify this in TTML2 like we agreed to do in TTML1.

Glenn: I think we agreed to do that already.

Pierre: We'll create a PR on IMSC1, on TTML1 and on here, and in the next couple of weeks
... we need to review that as a group.

Glenn: We already have a note to that effect on #439.

RESOLUTION: Treat as a duplicate of #439

github-bot, end topic

Glenn: [adjusts labels and closes issue]

Examples in section S use an unusual tts:displayAlign setting ttml2#459

github: https://github.com/w3c/ttml2/issues/459

Glenn: The `<br>` can go at the end of spans in the roll-up example safely because
... empty line area at the end of the paragraph is elided.
... I will fix the other comments on the pull request.

Duplicated text for attributes in TT Style Namespace. ttml2#438

github: https://github.com/w3c/ttml2/issues/438

Nigel: This was one where Nigel and Andreas both asked for clarity about TT Style Namespaces

Glenn: I can put a link to the statement where TT Style Namespaces is explained.

Update definition of [related media object region]. ttml2#360

github: https://github.com/w3c/ttml2/issues/360

Nigel: My question is why does presentation processing context need a non-null related media object?
... It is possible to present only the TTML content without a related media object.

Glenn: I see your point.
... I also said non-null _visual_ related media object. I think I recall the reason...
... [explains on whiteboard] We have logical pixels, display pixels, related media object,
... a hypothetical/virtual display device, and a real display device.
... The display pixels and the related media object both get composited in the virtual or
... hypothetical display device.
... In the presentation context I was trying to define the virtual/hypothetical display device.
... Now I write it down on the board I can see how it is possible to do this without the related
... media object - it doesn't negate the existence of the hypothetical display device.
... There was one place where I wanted to refer to pixels in this box, which is when position
... is defined on tt and there is a horizontal or vertical offset in pixel units used on that position
... attribute, I want it to be related to the hypothetical display device's pixels.

Nigel: Okay
... In all these cases you don't need related media object.

Glenn: I can go back and allow the related media object to be null.
... I'll also address the other pull request comment and add the "etc"

github-bot, end topic

Glenn: [takes the agenda label off] I will update the PR.

Specifying tts:position and tts:origin on the same element should be an error. ttml2#538

github: https://github.com/w3c/ttml2/issues/538

Pierre: The reason for having both is for compatibility with TTML1 but the document is
... presented differently by a TTML2 processor and a TTML1 processor if the values differ.

Glenn: If the author has specified both to present the same result then they will behave the
... same. It's only in the case that neither is present or if the values differ that the behaviours
... would differ. If the values differ that's the author's problem.

Pierre: We have created a potential for ambiguity here.

Glenn: Consider the region element - percentages matter and you cannot express, without
... knowing the root container, a fixed position of a region.
... For example positioning the region 10% from the bottom of the root container region.

Nigel: I don't think that's true.

Pierre: [also doesn't believe it]

Cyril: 5 cases to enumerate.
... 1. Neither origin nor position specified - TTML1 and TTML2 produce different results because the origin and position attributes have different initial values.

Nigel: How do you know it's a TTML2 document in that case?

Pierre: If you consider a TTML1 document is a TTML document that does not contain TTML2 features...

Nigel: You might not know from looking at the document.

Cyril: 2. Only origin specified.
... 3. Only position specified.
... 4. Both origin and position specifiewith the same intended result.
... 5. Both origin and position specified with different intended results.

Pierre: 2 and 3 are the easiest. In 2 the outcome is the same for both TTML1 and TTML2 processors.

Cyril: We may have to change the design from what we said yesterday to say that TTML1
... documents are only processed the same if they do not contain TTML2 features.

Nigel: Case 3 means a TTML1 processor will use the initial value of origin.

Pierre: Yes but the author has no expectation there.

Glenn: For 4 I assume the TTML1 processor will use origin and the TTML2 processor will
... use position and they will have the same result.

Pierre: From an authorial standpoint you don't need 4.

Glenn: It's okay with me if the author wants to do 5 but its undesirable.

Cyril: For 4, you get the same processing on both.

Pierre: It complicates the spec for no benefit, having to deal with the precedence rules.

Glenn: The alternative is that you tell the author what not to do and fail to define the
... processor behaviour then that processor behaviour is undefined so you're introducing
... an ambiguity.

Cyril: Talking about 1, what does it mean, that we have to change the initial value for position?

Pierre: Yes

Glenn: In that case if neither is present maybe it should use origin in the absence of any
... reason to choose TTML2 semantics.

Nigel: Can't we simply change the initial value of position to "top left"?

Cyril: I think there are lots of instances where initial values of position are used.

Glenn: Position is also used for image and background image and for consistency with CSS
... it has an initial value of "center".

Cyril: I would agree with Glenn that if the effective processor profile is TTML2 then use
... position, or if it is TTML1 then use origin.

Glenn: [slaps own hand] tts:position only applies to region, not to tt at all, and it is not used
... directly for background. What we have is a backgroundPosition attribute which is different.

Cyril: Scoping the problem, this is applicable only on region.

Andreas: Following the discussion I would be concerned if a document with neither origin
... nor position present would lead to a different result for TTML1 and TTML2 processors.
... The signalling of profile is not a big help. We should make sure this document will be
... rendered the same by both processor.

Nigel: So make the initial values coincident?

Andreas: Definitely.

Cyril: That goes against CSS alignment.

Glenn: Our use of position with region is different than its CSS use with image, so we can
... have a different initial value. But let me point out that we have an initial element.

Pierre: Netflix's real usage is an important data point which I would like to wait for.

Cyril: I will check.

Pierre: There's a thread going on where they point out that the three component value
... of the CSS position property can lead to syntactic ambiguities. Why do we support up
... to 4 value components?

Glenn: They had those in CSS - if they have taken them out then I don't know about that.
... If there's an ambiguity we have called that out and resolved it in our spec.

Nigel: I recall reviewing that and checking there was no ambiguity.

Pierre: Perhaps we can help with alignment and avoiding bugs by changing to follow the CSS change.

Nigel: Is the reduced syntax version of the CSS property in a spec in the current CSS snapshot?

Pierre: I will find the thread.

<pal_> https://github.com/w3c/csswg-drafts/issues/2140

Cyril: Propose to defer this question about the position property and attribute until the next call.

Nigel: Going back to this issue... The proposal is to prohibit both origin and position being
... present and remove the precedence rule.

Pierre: We can have a fallback precedence rule as well.

Glenn: I could live with that as a required error behaviour.

Pierre: I don't want to force a specific processor behaviour for handling an error condition.

Cyril: Previously it was not an error condition.

Glenn: I object to making it an error in documents.

Pierre: I'm trying to propose something like the behaviour in <timeExpression> where it
... is considered an error if some value formats are used.

Glenn: I have an action to go through the whole spec explaining processor behaviour if
... an error is encountered. What you are suggesting is to make a document non-conformant
... if both origin and position are present. I don't like it because you don't know what the
... target processor will be.

Nigel: Would a possible compromise be to define the behaviour with both present in TTML2
... and then if desirable prohibit them both being present in a profile?

Pierre: Yes, I'm trying to keep IMSC 1.1 as simple as possible, but that would work.

Glenn: I would accept.

Cyril: OK

Pierre: We still have to solve the initial value problem.

RESOLUTION: Close this issue without further action on the basis that additional document constraints can be applied in profiles if that is desirable.

github-bot, end topic

Nigel: I closed #538.

Cyril: I will open an issue for considering aligning the initial values of tts:origin and tts:position.
... That's opened as #551

TTML2 topics

Pierre: We should check the i18n issues.

13 i18n open issues

Cyril: Removing those, PR open, discussed and agreed and editorial then we have 38 issues open.
... Of those, many were discussed already but not concluded.

<cyril> is:issue is:open -label:"discussed and agreed" -label:editorial -label:"pr open" -label:i18n-comment sort:updated-desc

Nigel: [checks through issues marking discussed and agreed ones]

Remove root style inheritance functionality. ttml2#546

github: https://github.com/w3c/ttml2/issues/546

RESOLUTION: Remove root style inheritance functionality

github-bot, end topic

Require support for DFXP transformation and presentation profiles. ttml2#364

github: https://github.com/w3c/ttml2/issues/364

Nigel: We didn't note yesterday that the action here is to add support for the dfxp profile designator.

RESOLUTION: Add support for the dfxp profile designator.

github-bot, end topic

Definition of [construct effective content profile] does not take into account `ttp:profile` attribute value. ttml2#433

github: https://github.com/w3c/ttml2/issues/433

Pierre: Last time I checked the algorithm it did not take into account the value of ttp:profile attribute.

Nigel: Is the action clear?

Pierre: It is to add it to the algorithm.

Glenn: Maybe, I need to review why this is the way it is.
... It looks like there's circular text here because the algorithm seems to refer to itself. I need to review this.
... I will put it on my editors priority list.

Pierre: Feel free to prove me wrong and show that it is not needed.

Nigel: For example hypothetically maybe the algorithm never gets called when ttp:profile is present.

SUMMARY: @skynavga to review

github-bot, end topic

TTML2 issues run-through.

Glenn: Most of the issues opened on June 4 have an editorial comment in the spec.

Cyril: We don't need to discuss those now, but in the next couple of weeks.

Nigel: We're down to 27 open issues right now.

Cyril: Yes plus the i18n ones we should discuss.

Glenn: There are 12 WR-open issues that are not discussed and agreed.

Add support for font variation settings ttml2#399

RESOLUTION: WG recognises this may be a useful feature but defers to a future version.

github: https://github.com/w3c/ttml2/issues/399

github-bot, end topic

Nigel: I've commented on the issue and agreed the disposition and closed the issue and updated the labels.

Definition of [construct effective content profile] does not take into account `ttp:profile` attribute value. ttml2#433

github: https://github.com/w3c/ttml2/issues/433

Pierre: I've reviewed this and ttp:profile only ever applies to processor profiles so we can
... close this issue. I encourage further review of this area of the text.

RESOLUTION: No action required.

github-bot, end topic

Pierre: I'm going to mark as commenter agrees.


Nigel: reconvene in 25 minutes

<ericc> cyril: https://zcorpan.github.io/live-webvtt-viewer/

TTML1 issue status review

Cyril: TTML1 has 15 open issues.

Nigel: Thank you for getting through these so much over the past couple of months.

Cyril: Taking out PR Open ones goes down to 8, of which 4 are marked as editorial.

Pierre: I'm not sure if #228 is editorial in fact.

Cyril: It looks as though it relates to vertical writing modes which would be Japanese so
... we could consider that as something to defer from TTML1. It is handled in TTML2.

Glenn: [explains]

Nigel: So it's like CSS sideways-left and sideways-right

Glenn: I propose to defer this.

Pierre: There's not enough here to do anything so I propose to close the issue.

Glenn: +1

Cyril: OK

Nigel: I've commented on the issue and closed it.

Pierre: On ttml1#212 I don't know what to do with it.

Nigel: We've discussed the bpd of inline areas a lot and need a fix from CSS WG.
... I propose to close it with no change.

Glenn: I agree.

Pierre: I'm also blocked on ttml1#247.

Tess: I think the comma gets there because its the last character and has weak directionality.

Glenn: It takes the direction of the paragraph embedding level which is normal (left to right)

Pierre: Writing mode on region automatically sets direction.

Glenn: Right, and direction is inherited but writingMode is not.
... So the region writing mode of rl sets the direction to rl.

Dave: The example is correct because the comma is at the end of the text, which is the left,
... but it looks strange because the text is not normal looking right to left text.

Pierre: The direction is set via XSL.

Cyril: I'll open an issue to add a comment as per TTML2.

Tess: This is an awful example but it is correct. It's a great test case.

Nigel: I've added a comment to the issue and closed it.

Pierre: Looking at the no milestone issues, we have to decide which should be in TTML1 Third Ed.
... There are 9 open ones.

Nigel: We've reviewed the No milestones TTML1 issues and assigned those that we want
... to fix in TE to the 3rd Ed milestone.

Implicit durations of <set> and <br> not specified ttml1#310

github: https://github.com/w3c/ttml1/issues/310

Pierre: My proposal is to use the same implicit duration as anonymous spans.

Glenn: I agree with that.

Nigel: br is not a timecontainer because it has no begin or end.

Glenn: I think it does in TTML2, and it should have.
... In TTML2 we have added region, begin, end, dur and timeContainer attributes to br.
... We decided it was a bug not to specify it here.

Pierre: In TTML1 br and set are not time containers.

Glenn: br should be because it has timed animation children.

Pierre: In that case it must have only parallel time container semantics.

Cyril: We could solve it by removing animation class children.

Pierre: I'm happy to do that, or recommend non-use.

Glenn: the animation class has been there since first edition.
... What we did in TTML2 is fill it out, add the attributes.
... I would put an informative note recommending against use of any animation children in br.

Pierre: I'll file the issue.
... Then this issue is scoped only to set elements.
... I've filed #325.

SUMMARY: Pierre will add a disrecommendation for use of animation class children on br and state that the implicit duration of set is the same as anonymous spans.

github-bot, end topic

Discourage use of Animation class children elements of <br> ttml1#325

github: https://github.com/w3c/ttml1/issues/325

Nigel: I would expect a `<br>` that is a sibling of character content to be wrapped in the
... same anonymous span as the adjacent character content so that it has the same timing,
... regardless of the timeContainer parent.

Pierre: I understand what you're saying.

Nigel: (I mean I think authors would expect the br to be presented and not be a time separator)

Pierre: We could remove `<br>` from timing altogether but then what we did in TTML2
... would not work.

Glenn: The problem is the animation children of `<br>`.

Pierre: Right, we could remove those.

Chris: What if you want the `<br>` to have its tts:display attribute vary?

Pierre: You could wrap it in a span.
... What I'm hearing is that we want `<br>` to act as a character.

Glenn: It simplifies implementation. I don't know of any implementation that does anything
... with it like support animation.

Pierre: That would solve multiple problems.
... I'll propose a solution to that for TTML1 for next week's telecon.

SUMMARY: Pierre to propose a solution as per the above discussion for next week's telecon.

github-bot, end topic

TTML1 issues review

Nigel: We are left with 13 open 3rd Edition milestone issues.

Pierre: I've updated the pulls based on the discussion yesterday.
... Assuming we can solve the implicit durations on #193, #310 and #325 next week,
... then we can include them. Otherwise we can postpone CR or defer the issues.
... I think I'll be able to generate pulls for everything else in time for next week's meeting.
... Then the group will be able to make a go/no go decision next week.

IMSC issues review

Pierre: For IMSC 1.1 it's all in the Editor's court so there's nothing to do for the group.
... For IMSC 1.0.1 there's a minor editorial tweak open.
... Plus I will need to update the foreign namespace wording as discussed in this meeting.
... There's no particular timing driving 1.0.1 at the moment.

Nigel: We are blocked on progressing IMSC 1.0.1 until we get another implementation.

Andreas: IRT is working on an implementation that hopefully will be available in the next few weeks.

IMSC 1.0.1 implementation report

Pierre: Someone just posted a comment against 1.0.1 so I'll generate a pull request to address it.

TTML2 i18n issues.

Cyril: Let's work offline on those.

Glenn: I don't think it is worth us discussing them today.

TTML1 Third Edition CR Exit Criteria.

Pierre: There are no new features in TTML1 Third Ed but there are substantive changes.
... Those changes are where we have clarified ambiguities.
... The tests are unchanged.

Tess: Since the changes clarify some semantics, there should be tests that verify that the
... implementations meet the clarified semantics.
... Are you saying that the existing tests already tested for the now clarified behaviour then you're fine.

Pierre: That's exactly it.

Tess: Then the previous implementation report should work.

Nigel: It seems like a strange thing process wise to ask for CR exit criteria that include
... an empty test suite and therefore have no implementation report requirements.

Pierre: The key here is we have not added any features.

Tess: The important thing is the assertion that every substantive change has corresponding
... test coverage that was in the previous implementation report.

David: Then why bother to do a new edition if there's nothing new to test?

Glenn: For things like [associate region] I don't recall any explicit tests targeting that semantic.
... There may be aggregate tests that indirectly test it.

Pierre: We could add more tests.

Glenn: We could test each step in that algorithm.

Pierre: IMSC has tests for a number of them. We could move use IMSC 1 tests in.

Glenn: I suggest we enumerate all the substantive changes in TTML1 Third Edition,
... and evaluate what the impact on the test suite might be, e.g. "needs more tests",
... "test was too stringent" for example.

Pierre: I'm willing to do that - there will be very few.

Glenn: When we go to the Director we will need that ammunition.

Pierre: I am willing to test against imscjs if you're willing to test against ttpe for example.
... So we can generate tests for the clarified semantics.

Nigel: So we are not expecting an empty set of tests.

PROPOSAL: Require minimum of 2 implementations that pass each of the tests in the test suite, to be completed.

Pierre: I am happy to reference existing tests in imsc-tests for this purpose.

RESOLUTION: CR Exit Criteria of TTML1 Third Edition will be to show minimum of 2 implementations that pass each of the tests in the test suite, to be generated by inspection of the substantive changes relative to TTML1 Second Edition.

TTML2 CR Exit Criteria

Nigel: I think we need to base the exit criteria on the delta between TTML1 Second Edition and TTML2.

Cyril: +1

Glenn: To clarify, when we say features to be tested, are we talking about feature designators?

Nigel: The WG created those feature designators exactly for this purpose, to define what
... features need to have demonstrated implementations so I would propose to use them
... again here.

Cyril: Are we confident that there are no substantive changes in the TTML1 feature set that
... we don't need to test?

Glenn: It's up to decide, since we define the feature designators.
... We should have new feature designators where there is new syntax.
... If there are semantic enhancements that is the question.
... We should be able to trace substantial semantic changes to a newly defined feature designator.
... There does not need to be a 1:1 ratio of feature designators to changes, some feature
... designators can correspond to multiple changes.
... That delta between the TTML2 feature designators and the TTML1 feature designators
... gives us something to build the implementation report tests on.

Nigel: We need to do a piece of work to generate the feature designator list.
... We need to know the list before we request CR.

Cyril: Related question is the at risk features - do we need features for those?

Nigel: Of course yes.

Cyril: I am proposing that we get commitments for providing test vectors for features in the
... delta list. Things without any commitment for a test should be marked as at risk.

Nigel: Would you remove the features before CR if there's no commitment?

Cyril: Sure, maybe.

Andreas: I would support Cyril's suggestion. It makes sense to gauge interest in the features
... and implementations. It's an efficient way to work towards publication.

Nigel: I think we're thinking ahead to marking things as at risk in future CRs.

Glenn: I'm concerned about losing time by issuing later CRs.
... We should make an earlier call on likely at-risk features.

Cyril: We haven't discussed what type of implementation.
... There's also the question of what is an independent implementation.

Nigel: I believe two implementations from the same organisation can never be considered independent.

Tess: They're not externally verifiable as being independent.
... [has to leave]

Glenn: Back to transformation processor vs presentation processor. In the past we said
... either was fine and a validation processor is an example of a transformation processor.

Nigel: I don't see any reason to be more specific than to say "two independent implementations of each feature".

Glenn: I plan to provide two columns, enumerating the features that we validate and that we present.
... Then its up to the group to decide if it is one or two implementations.

Nigel: Why don't we say "including at least one presentation implementation"?

Glenn: That's reasonable except where there is no presentation semantic, such as the
... need to generate deprecation warnings.

Nigel: Then in the feature list we need to mark those features that have presentation semantics.

PROPOSAL: WG agrees TTML2 CR Exit Criteria are to have at least two independent implementations of each feature introduced in TTML2 where for presentation features at least one of those implementations is a presentation processor.

RESOLUTION: WG agrees TTML2 CR Exit Criteria are to have at least two independent implementations of each feature introduced in TTML2 where for presentation features at least one of those implementations is a presentation processor.


Nigel: Does anyone have any views about what should be in the next Charter period?

David: We should ask the meta question if this group is viable at all.

Andreas: An important topic also mentioned at TPAC is how subtitles for immersive media
... like 360 video, VR, possible AR.

Nigel: I would like to include a deliverable being a profile of TTML2 for audio description.

Pierre: My input on the Charter is purely editorial - it should be simpler. I would keep it
... to maintenance of IMSC and TTML family of standards.
... Modulo specific items like you mention. In general begin with maintenance.
... On the existential question, is that rhetorical?

David: No, it's a formal question since we may not get the minimum requirement to form the group.

Glenn: Does the same criteria apply to existing groups?

David: We should prepare for that discussion because this group is scarily small and the
... support from the AC is scarily low.

Pierre: I've discussed this a couple of times with Philippe but it's been hard to explain how
... many external organisations are looking to W3C.

David: The group seems to be competently handled so people don't feel the need to get involved.

Pierre: The cognitive dissonance is that this should heighten the W3C stature amongst
... standard bodies but somehow that is not the metric.

David: In some sense several of the members represent multiple organisations.

Pierre: Yes and some make lots of devices or have millions of customers.

Andreas: I would fully support what Pierre just said. In my experience a lot of standards
... bodies have dealt with subtitles and are very happy for W3C to be a convergence point
... where one standard is maintained and not one per standards organisation.

Nigel: We discussed this at TPAC and Wendy seemed to me to be completely satisfied that
... there is a strategic need to continue the group.
... For drafting purposes we need to list in the scope and deliverables section the things
... that we want to do, else we cannot do them.

David: Yes. the easy one is maintenance of Recommendations and things that are on the
... Recommendation Track.
... There may be an interaction with the new internationalisation process to raise the
... status of a whole bunch of language from bad support to mediocre and then to advanced.
... We should consider that as a possibility.

Glenn: Human languages?

David: Yes

Nigel: I guess that work could generate new presentation requirements for us to process,
... though we have been focusing on that for a while.

David: We need some vague enough wording in support of this.

Nigel: is this enough for us to start?

David: I think so yes, to do a clean up.

WebVTT transition to CR

<dsinger> I drafted https://lists.w3.org/Archives/Public/public-tt/2018Jan/0069.html

David: I'm aware that there are some issues open on WebVTT that Nigel opened and hasn't
... had time to review.
... In general I would like us to go to CR. How do you want to handle this?
... There are some formal things that you maybe would like to see done.
... Silvia is on vacation so she hasn't done the editorial work to make it look like a CR.
... So I don't have a document that looks like a Rec track document.
... I made up exit criteria.

Pierre: What Thierry has done in the past is create an implementation report wiki and point
... to that in the SOTD.

Nigel: I wouldn't put the implementations in two places, just put them in the Implementation Report.

David: Sure, so include the WPT results in the implementation report.

Cyril: You have a sentence about offering a wide review (third para).

David: Ok, sure that needs to be removed.

Pierre: What's the IPR situation with CG etc?

David: We brought it in from the CG, and we went through 6 months of pain getting IPR coverage
... for the spec text as it came into the WG.

Pierre: Since then the work has not happened in TTWG, so how to handle? Can you argue there are no new features so no IPR issue?

David: The only changes I could find are as listed.

Pierre: You should link to the GitHub PR.

David: The other is about conformance classes.

Pierre: And no other substantive changes?

David: That's a judgment call on what is a substantive change.

Pierre: I've suffered from that - the Process defines the substantive changes.
... In the past we have listed all substantive changes as defined there.

Nigel: We've found the process definitions to be useful even if we didn't want to agree with them.

David: Okay I can check.

Pierre: What we did was used GitHub. Who contributed those two major changes?

David: Silvia wrote the text, as a result of discussion with a bunch of people.

Pierre: Are they all TTWG members?

David: Yes they are.

Pierre: And no features have been added.

David: That's right. I will check GitHub pull requests.

Pierre: Don't include the not substantive ones.

Cyril: When we submit the transition to CR we don't have to provide the test suite?

David: Correct.
... The Group's requirements are the MAUR and I've copied that through and checked the list.

Eric: I checked the list too and didn't spot anything.

Nigel: It passed me by that we asked for HR for the most recent WD. Did we do that?

David: Yes, Thierry sent out the HR requests.

Nigel: In terms of the coordination part of the Charter there are lots of groups listed.
... It's not clear what we have to do with those - to be safe we should ask all of them for
... wide review input, but you could argue the case that only a subset is relevant.

David: [reviews process]
... There are no changes in dependencies with other groups.
... We sent liaisons to the external liaisons for the first wide review.
... There's a WebVTT wide review page - I hope it is correct.

Pierre: The "evidence that issues have been addressed" section should only list open unresolved issues.
... The objections should be moved to the Objections section.

David: I don't think there are any at risk features.
... The implementations page should be updated.

Nigel: I'm not convinced that you need section 10 Implementation Information to list actual implementations

David: I don't see any harm in telling the Director about existing implementations.

Pierre: You know that those are not complete yet? So in a sense that is evidence of wide review. The implementation report will show implementations.

Nigel: You don't need to report on feature coverage at this stage.
... So you want to know the steps needed to get to CR?

David: Yes, I don't think we can get to CR today since we need Nigel's input on some issues.
... We hope for review comment responses by Feb 15.

Pierre: You need this plus the disposition of the comments.

<dsinger> to proceed with the CR transition request (a) response from the commenter, or feb 15th, whichever is sooner, (b) the revised transition request and (c) a document prepared as a rec-track document (not CG report)

Meeting close

Nigel: Thanks everyone! [adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. Do not apply this change to TTML2, consider using in a future spec version or module.
  2. Remove ttp:mediaDuration
  3. Close without merging.
  4. Treat as a duplicate of #439
  5. Close this issue without further action on the basis that additional document constraints can be applied in profiles if that is desirable.
  6. Remove root style inheritance functionality
  7. Add support for the dfxp profile designator.
  8. WG recognises this may be a useful feature but defers to a future version.
  9. No action required.
  10. CR Exit Criteria of TTML1 Third Edition will be to show minimum of 2 implementations that pass each of the tests in the test suite, to be generated by inspection of the substantive changes relative to TTML1 Second Edition.
  11. WG agrees TTML2 CR Exit Criteria are to have at least two independent implementations of each feature introduced in TTML2 where for presentation features at least one of those implementations is a presentation processor.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/11 12:40:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/#443/ttml2#443/
Succeeded: s/e./e?/
Succeeded: s/Resolution/RESOLUTION/
Succeeded: s/because a/because/
Succeeded: s/d./with the same intended result./
Succeeded: s/4/.. 4/
Succeeded: s/289/551/
Succeeded: s/s././
Succeeded: s/I drafted/I recently drafted/
Succeeded: s|I drafted https://lists.w3.org/Archives/Public/public-tt/2018Jan/0069.html||
Succeeded: s/recently //
Succeeded: s/proe/proce/

WARNING: Replacing previous Present list. (Old list: Glenn, Cyril, Chris, Pierre, David, Tess, Eric, Nigel)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Glenn, Pierre, Eric, Nigel

WARNING: Replacing previous Present list. (Old list: Glenn, Pierre, Eric, Nigel, Andreas, Chris, Tess)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Andreas, Chris, Tess

Present: Andreas Chris Tess
Regrets: None
Found Scribe: nigel
Inferring ScribeNick: nigel
Found Date: 10 Jan 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]