See also: IRC log
<scribe> scribe: nigel
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 issues and pull requests labelled "agenda"
github: 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.
github: 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.
Nigel: Please could someone review this pull request?
Glenn: It's on my list.
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 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.
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.
github: 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.
github: 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
Cyril: We have some pull requests that are blocking. I also count 13 open issues.
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.
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