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]
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
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
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
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
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
Glenn: I plan to do this.
RESOLUTION: WG agrees to add this as requested, subject to Editor input
github-bot, end topic
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
test
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.
<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.
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.
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
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
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
Nigel: Since we resolved not to add @ttm:alt we should close this pull request.
RESOLUTION: Close without merging.
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]
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.
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.
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.
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
Pierre: We should check the i18n 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]
github: https://github.com/w3c/ttml2/issues/546
RESOLUTION: Remove root style inheritance functionality
github-bot, end topic
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
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
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.
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.
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/
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.
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
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
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.
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.
Cyril: Let's work offline on those.
Glenn: I don't think it is worth us discussing them today.
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.
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.
<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)
Nigel: Thanks everyone! [adjourns meeting]
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]