Re: Objections to Netflix Proposal from 2017-11-15

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.