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

> 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 Thursday, 30 November 2017 21:05:53 UTC