- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 3 Oct 2017 08:40:57 -0700
- To: Michael Dolan <mike@dolan.tv>
- Cc: "public-tt@w3.org" <public-tt@w3.org>
> 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. P.S.: ... and additional functionality in the case of TTML2 image, e.g. unambiguous content type and image characteristics signaling. On Mon, Oct 2, 2017 at 8:39 PM, Pierre-Anthony Lemieux <pal@sandflow.com> wrote: > 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 15:49:06 UTC