Re: IMSCvNEXT kick-off + FPWD + liaisons

Hi Mike,

Thanks for the quick review.

> So, changing all references from TTML1 to TTML2 is a pretty risky thing

Yes it is risky, especially in light of the rewrite of sections from
TTML1 to TTML2, e.g. the one specifying style inheritance.

There is a related issue against TTML2 [1] recommending that TTML2 be
explicitly be made compatible with TTML1.

[1] https://github.com/w3c/ttml2/issues/442

The upside is a cleaner specification that is based on the stated
long-term goal of TTWG to move to TTML2 as the basis for future
development.

IMHO this upside has to be balanced with the risks above and the
desire to make prompt progress.

> Why is #image (from SMPTE namespace) deprecated?

Requirements discussion have so far pointed to a desire to replace
non-TTML2 features (e.g. smpte:backgroundImage) with TTML2 equivalents
(i.e. image) in the long run. A downside is the immediate impact on
current implementers, and risks of adopting a new feature.

I suggest adding both of the topics above to a future TTWG call. When
do you plan on attending?

Best,

-- Pierre

On Mon, Oct 2, 2017 at 1:46 PM, Michael Dolan <mike@dolan.tv> wrote:
> Pierre,
>
> Thanks for the quick work. I have a couple concerns about backwards compatibility with IMSC1.0.1.
>
> Given the W3C practice of copying provisions in version N rather than normatively referencing version N-1, the opportunity for incompatibility is pretty moderate.  So, changing all references from TTML1 to TTML2 is a pretty risky thing to do in a new profile where we intend that it be compatible with version N-1, specifically such that IMSCvNext rendering results in the same output as from IMSC1.0.1.  Unless there is a conscious intent to extend a TTML1 feature in TTML2 it would be a lot safer to reference TTML1 for all the features found in IMSC1.0.1 and only reference TTML2 for new features or features that were intentionally extended in a backwards compatible manner.
>
> Why is #image (from SMPTE namespace) deprecated?
>
> The inclusion of #textShadow may enable one or two text attribute deprecations. When defining IMSC1 we did an alternative "best fit" for 708 requirements using some other text attributes for what textShadow can do.  I'll study this "soon" and make a proposal. It's probably not very likely that the alternatives were actually used.
>
>         Mike
>
> -----Original Message-----
> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
> Sent: Monday, October 2, 2017 9:02 AM
> To: public-tt@w3.org
> Subject: IMSCvNEXT kick-off + FPWD + liaisons
>
> Good morning/evening,
>
> I have pushed an initial Editor's Draft of IMSCvNEXT under the IMSCvNEXT branch [1].
>
> [1] https://github.com/w3c/imsc/tree/IMSCvNEXT
>
> The specification can be viewed at [2].
>
> [2] https://rawgit.com/w3c/imsc/IMSCvNEXT/imsc1/spec/ttml-ww-profiles.html
>
> The ED is based on the current requirements document [3].
>
> [3] https://w3c.github.io/imsc-vnext-reqs/
>
> As described at [3], IMSCvNEXT is intended to retain the scope of
> IMSC1 while adding the minimal set of features necessary to support current practices for worldwide subtitling and captioning delivery.
> >From a high-level, it looks like the bulk of the IMSCvNEXT
> improvements will center around Japanese language, HDR and stereoscopic support.
>
> As discussed during our last telecon, I suggest publishing a FPWD this week or next week and informing external organizations that the work has started.
>
> Best,
>
> -- Pierre
>
> P.S.: It would be good to settle on a version number promptly, lest some folks call it vNEXT forever.
>

Received on Tuesday, 3 October 2017 03:40:24 UTC