Animate @calcMode value displace{,d} should read paced.

[skynavga]

Typo in both XSD and RNC schemas where paced is written as displace{,d} as well as in section 13.3.3 <calculation-mode>, where paced is missing.

[nigelmegitt]

This is a substantive change since it introduces new syntax not previously included, even if that omission was unintended - I certainly had no idea that it was anyone's intention to include paced.

[skynavga]

@nigelmegitt I was torn on how to label it, so that is fine. Its absence is clearly an oversight, and was intended to be there (as indicated by the schema, though it wasn't correctly specified there either). In any case, we should make a determination on its inclusion, since I did not intend to exclude it and AFAIK, we have not discussed it in the group. My intent for <animate> was to have functional parity with SVG 1.1 which, in turn, is based on SMIL 3.0. That being said, I would not object to deferring support for paced to TTML3, etc. However, we expect that TTPE will support it in the TTML2 CR(s) time frame.

[nigelmegitt]

@skynavga I'll add this to the agenda so we can discuss it before making a determination.

[css-meeting-bot]

The Working Group just discussed Animate @calcMode value displace{,d} should read paced. ttml2#699, and agreed to the following resolutions:

• RESOLUTION: Add paced calcmode and feature designators for paced and spline calcmodes.

The full IRC log of that discussion

<nigel> Topic: Animate @calcMode value displace{,d} should read paced. ttml2#699
<nigel> github: https://github.com//issues/699
<nigel> Glenn: Apparently we had a discrepancy between the schema and the spec in regard to the
<nigel> .. "paced" value of the calcmode. There was incorrect and incomplete schema support that
<nigel> .. wasn't mentioned in the spec. There was never any discussion or proposal to exclude it
<nigel> .. so my conclusion was that it was not intended to be excluded and it needs to be fixed
<nigel> .. in the schema and added to the spec.
<nigel> .. If it turns out there are insufficient implementations then we could remove it.
<nigel> .. I plan to add a pull request to make the animation features more functionally oriented
<nigel> .. than syntactically oriented. We need one targeting paced and spline modes. That leaves
<nigel> .. two other modes, linear and discrete. Linear is the default, discrete turns it into the same
<nigel> .. as set semantics with multiple entries.
<nigel> .. If you're going to support animate at all you should definitely support linear mode, and
<nigel> .. there's no harm in requiring support for discrete at all since we already have it via set.
<nigel> .. My thinking is that the default feature identifier should translate to mandatory support
<nigel> .. for linear and discrete, however the other two, paced and spline add a fair amount of
<nigel> .. additional complexity and attributes so I think they should have their own feature designators.
<nigel> .. Key times is required by both, and key splines by spline mode only. I plan to open another
<nigel> .. pull request to orient along those latter two.
<nigel> Nigel: You said non-discussion implied not excluding, but you could just as well say that
<nigel> .. non-discussion meant non-inclusion.
<nigel> Glenn: It looks like an accidental exclusion not an intentional one.
<nigel> Nigel: Okay let's not dwell on it, I think we only reviewed the spec in front of us.
<nigel> .. Anyhow does anyone have any views about introducing paced? It seems like good functionality to me.
<nigel> group: [no further views]
<nigel> Glenn: Does anyone object to adding the feature designators for paced and spline?
<nigel> Nigel: Seems like a good idea to me.
<nigel> group: [no objections]
<nigel> Glenn: I've already implemented validation.
<nigel> RESOLUTION: Add paced calcmode and feature designators for paced and spline calcmodes.