- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Fri, 1 Dec 2017 11:14:22 +0000
- To: Pierre-Anthony Lemieux <pal@sandflow.com>, Glenn Adams <glenn@skynav.com>
- CC: TTWG <public-tt@w3.org>
Note that EBU has changed approach and, as we saw with fillLineGap for example, has now begun to ask for new features to be implemented by W3C before adopting them. It is in our control to decide for example what namespace to use. I'm repeating myself, but for me our ability to be responsive in our specifications is better served by connecting groups of specifications together, where each encapsulates a subset of functionality, and can be updated on its own more easily. TTML styling is the primary example of this. On 30/11/2017, 21:05, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote: >> Following the same logic, the W3C should have objected to EBU adopting >>but then changing the semantics of TTML vocabulary. > >TTWG should be responsive and welcoming to external feedback, such >that features that have broad interest have a greater chance of being >directly included in W3C namespaces -- removing the need for >organizations to come up with extensions in their own namespaces, at >the risk of diverging from the core TTML specifications. > >On Thu, Nov 30, 2017 at 6:54 AM, Glenn Adams <glenn@skynav.com> wrote: >> SIL >> >>> > -----Ursprüngliche Nachricht----- >>> > Von: Andreas Tai [mailto:tai@irt.de] >>> > Gesendet: Donnerstag, 30. November 2017 14:15 >>> > An: 'Timed Text Working Group' <public-tt@w3.org> >>> > Betreff: Objections to Netflix Proposal from 2017-11-15 >>> > >>> > Dear all, >>> > >>> > As clarification seems to be needed in terms of W3C process: IRT >>> > objects >>> to >>> > the Netflix proposal made by Cyril Concolato on 2017-11-15. >>> > >>> > XML Attribute vocabulary that have been established in standards for >>> > years >>> > like linePadding and multiRowAlign should only be defined in their >>> > current >>> > namespace (in this case "urn:ebu:tt:style"). >> >> >> Following the same logic, the W3C should have objected to EBU adopting >>but >> then changing the semantics of TTML vocabulary. >> >>> >>> The attributes local names >>> and >>> > their semantics should not be copied to another namespace (in this >>>case >>> > "http://www.w3.org/ns/ttml#styling"). Especially for systems that are >>> > implemented into hardware like TV sets or set top boxes it takes a >>>lot >>> > of >>> time >>> > until market penetration is reached. System manufacturers therefore >>>need >>> to >>> > trust in the stability of standards over a long period. >>> > >>> > To signal now deprecation of these attribute vocabulary and to just >>> re-define >>> > them in another namespace disrupt successful market adoption of TTML >>> > standards and will raise doubts in the stability of TTML related >>> > standard >>> > activities. >>> > >>> > This may be especially true for the attribute fillLineGap. The >>>standard >>> that >>> > defines that attribute (IMSC 1.0.1) will (hopefully) reach REC >>>status in >>> 2017. If >>> > the publication of the next version of IMSC (version 1.1) is already >>> > deprecating this attribute in the same year and will define it in >>> > another >>> > namespace this gives a strong impression of a volatile standard >>> > activity. >>> > >>> > We do not see any technical reason to keep all vocabulary commonly >>>used >>> > in >>> > a TTML document in namespaces defined by TTML 1 and 2. In recent >>> > implementations we have not seen problems to use namespaces defined >>>by >>> > EBU-TT-D, IMSC and TTML in one document. >> >> >> That is because you are coming at this from the perspective of a >>deployed >> profile that draws from multiple core and profile specifications. TTML, >>on >> the other hand, being a core specification, does not and should not >> incorporate features from profile specifications, but may consider >> repurposing extension features for use in the core, a process that >> necessarily requires namespace normalization and possibly other changes. >> >> New versions of existing profiles are free to make use of new core >> functionality and determine independently whether and when to >> deprecate/obsolete older formulations. >> >
Received on Friday, 1 December 2017 11:14:50 UTC