- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 8 Feb 2018 17:25:20 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D6A23848.549C3%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2018/02/08-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
08 Feb 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/02/08-tt-irc
Attendees
Present
Andreas, Pierre, Cyril, Mike, Thierry, Nigel, Glenn
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This Meeting
2. [5]TTML2 agenda issues
3. [6]Fill in definition of tts:fontSelectionStrategy,
add to schema, fix typo ttml2#632 (pull requests)
4. [7]Loosen coupling between item name="usesForced" and
forced. ttml2#609
5. [8]Make begin times relative to the document temporal
coordinate space (#512) ttml2#616 (pull request)
6. [9]Improve animation value syntax (#383). ttml2#608
(pull request)
7. [10]consider removing recommendations that do not
appear to address a technical problem imsc#329
8. [11]Feedback on HDR compositing ttml2#400
9. [12]Next step to TTML2 CR
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This Meeting
Nigel: We've a packed agenda today so I'm hoping we can move
through all the issues
... rapidly with a minimum of technical discussion, so we have
a clear view of the steps
... to CR for all our specifications that we're working on by
the end of the meeting.
... We have lots to cover on TTML2, TTML1 and IMSC, primarily
issues or pull requests
... labelled "agenda" but also I think we need dispositions on
all the open TTML2 issues
... that need to be resolved before we request transition to
CR.
... Any other points to raise or other business?
... One small AOB: the request for a joint meeting with APA -
currently it looks like Feb 28
... is the best day - please respond offline to my email.
group: [no other business]
TTML2 agenda issues
[15]TTML2 issues and pull requests labelled "agenda"
[15] https://github.com/w3c/ttml2/labels/agenda
Fill in definition of tts:fontSelectionStrategy, add to schema, fix
typo ttml2#632 (pull requests)
github: [16]https://github.com/w3c/ttml2/issues/371
[16] https://github.com/w3c/ttml2/issues/371
Nigel: I'm proposing to defer this as I noted earlier.
Glenn: I object to deferring it for the following reasons:
... 1. It is not complex. The "auto" value is already implied
by our processing model, silently.
... It's been a long standing open area to flush out. As it
turns out the way that "auto" is
... technically defined is implementation dependent, but it
does at least give some guidelines
... as to what information constitutes the selection criteria,
which we had not listed before
... As for filling in the placeholder, we already had
enumerated the style property as a token
... in the list of vocabulary, and defined a feature for it.
Not much was required to fill in the
... gap to establish the two values. Nigel had even put in the
derivation previously.
... Really the only issue is whether or not we will have enough
implementations to satisfy
... exit criteria. We certainly have them for parsing the
property (TTT already does it). The
... semantics of auto are already supported in at least one
implementation. I think it will
... meet the CR exit criteria without any real issues. I don't
see any issue with including it
... and pulling it out now would prevent us from putting it in
CR and offering it to industry to
... implement. We could mark it as at risk - it is already
marked as at risk in this pull request.
Andreas: I tend to agree with Nigel. People have to review
deeply. There's some reference
... to XSL-FO so if there is no strong demand for it then I
would defer it. I think there has
... not been enough review.
Nigel: For me this is not simple at all - reviewing in terms of
XSL-FO and CSS is certainly
... complex.
Glenn: The text in this pull request is not complex - if you
try to understand XSL-FO and CSS then that is more complex.
... I'm aware of XSL-FO implementations of
character-by-character and it's extremely simple.
... All the character value does is to turn off contextual
characters and treat each character
... individually. CSS adopts the same thing there. There's no
danger in putting it in now.
Nigel: What is the use case for it?
Glenn: If you're using complex scripts and you have a list of
fonts, e.g. "Monaco, UnicodeMS"
... then Monaco as a font may not support all non-spacing marks
and UnicodeMS is much
... fuller and does support them. The "auto" semantic would
fall back to the UnicodeMS font,
... and might render it all in that font, but if the user
wanted the base character in Monaco
... and the generic glyphs for the combining characters from
the UnicodeMS font. The auto
... behaviour would not do that.
Nigel: Have any users ever asked for this?
Glenn: I'm aware of it in XSL-FO. We really need it for the
auto semantics. If we did not
... specify this feature then we have a gap in that we have not
defined the implied automatic
... semantics anywhere. If we did not do that then we would
have to have a special semantics
... subsection for font selection.
Nigel: This wasn't a problem in TTML1, and nobody has asked for
it.
Glenn: Saying nothing doesn't address this.
... It's been recognised for a long time that this is a missing
piece of specification material,
... going back to the change proposals.
Nigel: I think we have not enough time to add this detail now.
Glenn: If we cannot merge the pull request then let's see.
Andreas: What is the process if we cannot agree the pull
request?
Nigel: I think if we cannot merge it we cannot publish a CR
with an empty section in it, so
... we have to defer by default.
Glenn: There's no risk to the group since if a problem is found
then the feature can be
... removed post-CR, since it is marked as at risk.
Pierre: There's risk to the group because this takes our time
away from dealing with features
... that users have asked for.
Andreas: Not sure if I'm being naive here but I assume that at
risk features in a CR have
... been reviewed carefully by the WG, and it is only at risk
because there may not be enough
... implementations for it. In this case it is not reviewed
sufficiently, and there are concerns
... so there are two options: Wait until we can resolve it, or
defer it. We did not want to wait,
... so I don't see where we have a lot of options other than to
defer it.
Pierre: If the question is between deferring and missing the
deadline then defer it.
Glenn: The group can say include it right now.
Pierre: I think this is a request to merge this without review.
Glenn: No, I'm not suggesting to thwart the 14 day cycle.
Pierre: In order to go to CR today we have to do that.
Nigel: We said in one week's time.
Pierre: That's fine.
... I don't have a large stake in this, but if someone is going
to object to going to CR
... because of this then that's a problem for me.
Nigel: My problem with this PR is that it is too late.
Glenn: I don't accept that. We're done when we're done.
Pierre: We have to be done in one more week.
... If we merge this today then I will object.
Glenn: I will object to going to CR without this being
included.
Nigel: At the moment I have an objection to merging as is, per
my pull request review.
Glenn: You can record in the minutes that I'm objecting to
removing this.
... We either need to merge this or merge an alternative pull
request to remove it.
Loosen coupling between item name="usesForced" and forced. ttml2#609
github: [17]https://github.com/w3c/ttml2/issues/609
[17] https://github.com/w3c/ttml2/issues/609
Glenn: Again here I object to removing it. I do not object to
modifying the text to allow
... it to cover other uses besides condition, which I think was
the reason that this came up
... in IMSC context, because IMSC 1.1 does not include
condition (yet).
Pierre: I'm going to call for consensus to accept the pull
request to remove it, because at
... the moment it is not useful.
Andreas: I agree.
Nigel: I agree.
Cyril: Everything that makes it ambiguous for IMSC 1.1 in terms
of forcedDisplay should be
... cleaner. Glenn's proposal is to modify the usesForced
parameter to make it clearer, and
... I haven't seen the usage for it, so my preference is to
remove it.
Glenn: The use case for this is to provide a top level way to
determine if the document
... uses forced or not and process it in a special way if it
does uses forced.
Cyril: That's the problem. Pure metadata is maybe harmless, but
if there is processing
... associated then that's a problem.
Glenn: It's metadata but no processing is defined in the spec.
Pierre: My point is that will lead to intense confusion if some
application uses it.
Nigel: No case was ever made for this named metadata item - it
was added without discussion.
... I'm not aware of anyone who has ever asked for it.
Cyril: I want to remove this.
Pierre: I propose to remove it and if Glenn wants to object to
it then log that and take it forwards.
Nigel: To do that then I will have to dismiss the review and
merge it. I would then have to note the objection and carry it
forward in the CR transition request.
Glenn: I would note that the WG has signed off on this feature
previously in other WDs in
... which this feature was included. Now the group is
attempting to remove it without
... identifying the feature as at risk, which can be done more
easily.
Cyril: I propose a different option - the IMSC issue is about
the feature being too broad.
... I propose two features, one per named metadata item
#usesForced and #altText.
... Would that resolve it in IMSC1.1 Pierre?
Pierre: That would resolve it for me since I could prohibit it
from IMSC 1.1.
Glenn: You want feature designators for individual named items?
I could accept that.
Nigel: That would not resolve my issue, which is that
prohibiting metadata items within
... IMSC 1.1 that are harmless is too draconian.
Glenn: My alternative proposal is to make the change to
usesForced so that it does not
... require condition, so that it could be used in IMSC 1.1.
Nigel: The best option here is to remove the usesForced
metadata item.
Pierre: I'd rather remove usesForced than have Nigel's
objection.
Andreas: What was your objection Nigel?
Nigel: It is too draconian and if it is useful then it would
force people who for some reason
... do want to use it to use a different named metadata item,
which is crazy.
Glenn: I agree that the prohibition is draconian.
Cyril: If we were to do nothing in TTML2 we could simply add a
note to IMSC 1.1 that for
... the avoidance of doubt, because condition is prohibited in
IMSC 1.1 then the metadata
... item is also prohibited.
Nigel: You could say it is "not applicable".
Glenn: I would say "it does not apply", which is different than
prohibiting it.
... Right now in TTML2 it is well defined and there's no
technical problem. The issue is only
... with IMSC, which could add clarifying semantics about the
exclusion of condition, to say
... that usesForced is predicated on condition and therefore
does not apply.
Cyril: I would be okay with this pull request not being merged
on the basis of that update
... to IMSC 1.1, because it basically cannot be used.
Pierre: That's my conclusion as well, so I wanted to prohibit
it in IMSC 1.1 to avoid any
... confusion.
Cyril: The fact that it is prohibited is just a consequence not
an extra syntactical constraint.
Andreas: Would that be acceptable for Nigel and Pierre to use a
SHOULD?
Cyril: It cannot be a SHOULD, the document would just be wrong
if it is used.
Nigel: Actually using usesForced="false" would be fine.
... You could have a document that does that and uses IMSC 1.1
usesForced semantics,
... which would be technically correct but rather confusing.
Cyril: I would prohibit usesForced altogether, on the grounds
that usesForced="false" cannot
... be meaningfully used.
Glenn: I'm hearing a proposal to add #usesForced in TTML2 - I
would have no problem with that.
... I would also note that the description of usesForced needs
an addition to say that absence
... from the document does not imply anything.
Pierre: Would you be okay to re-evaluate your objection to
prohibiting it?
Nigel: I need to think about that. I still think that the best
thing is to note that it does not apply.
... Are you going to abort processing because of the presence
of metadata?
Pierre: For the sake of making sure people don't make mistakes
we should prohibit it.
Glenn: By that argument you should prohibit all metadata in
case it is misused.
Nigel: I think it is crazy to abort processing because of the
presence of metadata, and
... I don't think anyone would really want to do that.
Cyril: I don't think the proposal is to abort processing.
Nigel: I think it is.
Cyril: The document processor has the freedom to process
invalid documents.
... A validator though would detect this and say something is
wrong.
Nigel: A warning would be sufficient.
Glenn: If you said "should not be present" then that would
generate a warning.
Nigel: Pierre, mirroring your request earlier, would you
reconsider your prohibition proposal?
Pierre: No presentation processor does validation, practically,
in the field.
SUMMARY: There are a variety of options and we have no
consensus right now.
... 1. Remove the feature from TTML2.
... 2. Generalise the description in TTML2 further than
condition.
... 3. Define a feature designator in TTML2 called
#metadataUsesForced (or something similar)
... 4. Do nothing in TTML2 and let IMSC add language to
prohibit
... 5. Do nothing in TTML2 and let IMSC note the
non-applicability, plus possibly recommend non-usage.
Make begin times relative to the document temporal coordinate space
(#512) ttml2#616 (pull request)
Nigel: Please could someone review this pull request?
Glenn: It's on my list.
Improve animation value syntax (#383). ttml2#608 (pull request)
Cyril: If I understand correctly the change from string to [^;]
is too wide. That looks editorial, right?
... Glenn, can you change it to a less wide expression?
Glenn: No.
Cyril: Why?
Glenn: There's nothing broken - as per
[18]https://github.com/w3c/ttml2/pull/608#discussion_r166958259
... it is irrelevant - this applies to delimiters and control
characters. If it passes XML parsing
... then it's okay.
[18] https://github.com/w3c/ttml2/pull/608#discussion_r166958259
Nigel: That's new information, and useful. OK.
Glenn: If we had a DOM then technically it could be difficult
to serialise, but it could still be escaped.
Cyril: I'm approving this.
Nigel: Me too.
consider removing recommendations that do not appear to address a
technical problem imsc#329
github: [19]https://github.com/w3c/imsc/issues/329
[19] https://github.com/w3c/imsc/issues/329
Mike: I ran across the spec, and there were two SHOULD
provisions about authoring and
... they don't seem to solve any problem and put unnecessary
constraints on the authoring,
... at least at the recommendation level, and that seems weird
to me.
Nigel: I believe the cellResolution SHOULD is because we did
not want to rely on default values.
Mike: Then lots of other default values need additional text.
Andreas: In this case the cell resolution is used even when the
c unit is not used.
Glenn: I suspect it was done by analogy to pixel, where there
is no default extent on the root.
... In this case I agree it is unnecessarily overconstrained.
Pierre: It traces history way back including EBU-TT-D.
Andreas: I see both sides - especially on cellResolution a
general recommendation to set it
... can make sense.
Pierre: The reason it was put in there was because at some
point in an early EBU-TT-D draft
... it was mandatory.
Mike: But it is not now.
Pierre: There's a desire for EBU-TT-D to be a subset. That
meant we could not prohibit it in IMSC1.
Nigel: Can I propose to remove this cellResolution
recommendation?
Pierre: No objection for IMSC 1.1. We tried to minimise changes
to IMSC 1.0.1 and if we
... change it there then some validators will complain wrongly.
Andreas: I would also go with that. There have been liaisons
exchanged with other groups
... and I'm not sure about the other standards organisations'
responses to changing 1.0.1.
... It could be viewed as a substantive edit.
Mike: I don't feel strongly about acting on this in 1.0.1.
RESOLUTION: Remove the recommendation to include cellResolution
in 1.1
Mike: Moving on to the second one about time expressions using
the same syntax.
... There are good authoring reasons not to conform with this.
Andreas: I made a comment also, agreeing with this.
Nigel: I can't recall why this is present.
Pierre: This came from CFF-TT - I can only assume that it was
an attempt to stop authors
... from making things more complicated. I'm not aware of any
technical reason for this constraint.
Mike: I do not recall anything either.
Pierre: I think it can be removed.
RESOLUTION: Remove the recommendation to use the same time
expression syntax throughout a document in 1.1.
Mike: I'll change the label to 1.1.
Pierre: I'll prepare a pull request.
Feedback on HDR compositing ttml2#400
github: [20]https://github.com/w3c/ttml2/issues/400
[20] https://github.com/w3c/ttml2/issues/400
Nigel: This is just to check there are no comments on the draft
response prepared by Pierre.
... [time passes] That's a no. I'll go ahead and send this.
Thank you for preparing that, @palemieux.
github-bot, end topic
Next step to TTML2 CR
Cyril: We have some pull requests that are blocking. I also
count 13 open issues.
<cyril>
[21]https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Ai
ssue+is%3Aopen+-label%3A%22pr+open%22+-label%3A%22pr+merged%22+
-label%3A%22no+change%22+-milestone%3A%22Post+CR1%22+-label%3Ae
ditorial+-label%3Attml.next
[21] https://github.com/w3c/ttml2/issues?utf8=✓&q=is:issue+is:open+-label:"pr+open"+-label:"pr+merged"+-label:"no+change"+-milestone:"Post+CR1"+-label:editorial+-label:ttml.next
Cyril: this removes everything post-CR1, everything editorial,
everything ttml.next, everything
... with a pr open or merged, and there are 13 remaining
without pull requests. How are
... we going to proceed with these. If we open a pull request
today then we will not have
... a CR ready for two more weeks, right?
Nigel: Correct.
Cyril: I would like to defer all these issues. Can we defer
them to ttml.next or is there any
... pressing issue to be handled now.
Nigel: I would exclude the discussed and agreed ones.
Cyril: We will have to create a pull request anyway for those,
like #280.
Nigel: Correct, but we need to resolve it anyway because it is
a wide review comment.
Cyril: Glenn, can we defer those, or some of them, or what is
the status?
Glenn: I would like to have until the weekend to make as much
progress on these as I can and
... by Sunday if I have not dealt with any of them or asked for
help and got it then I will
... propose some action that might involve deferral.
... #365 and #366 are about three quarters done with a pull
request.
... The sideways issue should easily be taken care of.
... Looking at each of these individually, some of them involve
things that are broken or
... underspecified, like #495, so things in the broken
category, or potentially fatally
... underspecified, should be dealt with sooner rather than
later. The question is does any
... of them require adding a new feature. One thing I need to
do also is make a final pass
... at reviewing the feature designators with respect to the
new features we've added.
... Someone else could do that, it would be helpful.
... #379 could probably be deferred.
Cyril: Can we do it now?
Glenn: The intent of #379 is more advisory than a semantic
change, just adding the
... qualifiers to the profile document.
Nigel: That can happen after CR.
Glenn: I agree.
Nigel: I've changed the milestone.
<glenn>
[22]https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Ai
ssue+is%3Aopen+-label%3A%22pr+merged%22+-label%3A%22pr+open%22+
-milestone%3A%22post+cr1%22+-label%3Awr-for-disposition-action
[22] https://github.com/w3c/ttml2/issues?utf8=✓&q=is:issue+is:open+-label:"pr+merged"+-label:"pr+open"+-milestone:"post+cr1"+-label:wr-for-disposition-action
Cyril: If we use Sunday, which is the 11th, then the earliest
interpretation is 10 days later,
... which is 21st, being the earliest we could go to CR. That
means any changes would need to be made by the 11th.
Nigel: We already said this deadline was the 1st - we can't
just keep moving the deadline.
Pierre: We should just defer to another CR.
Glenn: That would create more delay. I would be happy to manage
the 22nd.
Nigel: I could accept that, but the strong view of the group
earlier was not to slip that late.
Cyril: I propose a call on Monday to review where we are up to.
Pierre: Works for me.
Glenn: I could do the same time on Monday.
Nigel: I can't do that - I have a prior commitment.
Cyril: Tuesday?
Nigel: I could do Tuesday
Glenn: Fine with me.
Pierre: I can only do one hour on Tuesday.
Glenn: I could do that.
Nigel: Okay, I'll schedule that for 10am Boston on the 13th.
Andreas: I will not be able to make it but it is fine if you go
ahead.
Cyril: The goal is to review the PRs that have been opened and
mark all issues with no pull request
... as deferred.
Glenn: I would call it 'final triage', and make a decision on
that basis.
Nigel: I or someone else could just go through the issues
without pull requests on Monday
... and defer them.
Glenn: Can I do that on Sunday?
Nigel: Yes!
... We won't have an additional meeting on Tuesday then.
... I'll send an email on Monday asking for consensus to defer
all the remaining issues.
Cyril: Then on the Thursday call we only have to discuss
existing pull requests.
Nigel: I would also ask that active members positively approve
everything that they're okay with
... to offset the risk of a later objection.
Glenn: Also please consider carefully if you're going to
request a change based on purely
... editorial issues.
Nigel: We're out of time, thank you everyone. [adjourns
meeting]
github-bot, end topic
Summary of Action Items
Summary of Resolutions
1. [23]Remove the recommendation to include cellResolution in
1.1
2. [24]Remove the recommendation to use the same time
expression syntax throughout a document in 1.1.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [25]scribe.perl version
1.152 ([26]CVS log)
$Date: 2018/02/08 17:13:14 $
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 8 February 2018 17:25:51 UTC