This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28259 - [webvtt] Normalization and string identity issues [I18N-ISSUE-425]
Summary: [webvtt] Normalization and string identity issues [I18N-ISSUE-425]
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: Web Media Text Tracks CG
Whiteboard: widereview
Depends on:
Reported: 2015-03-22 00:07 UTC by Silvia Pfeiffer
Modified: 2015-11-25 16:06 UTC (History)
6 users (show)

See Also:


Description Silvia Pfeiffer 2015-03-22 00:07:33 UTC
Feedback by Addison Phillips from W3C I18N group:

I18N comment:

Various constructs such as 'cue identifier' are described as being:

...any sequence of one or more characters not containing the substring "-->"...

The document makes understood that this is a sequence of Unicode characters. However, it leaves open the question of whether different Unicode character sequences that represent the same semantic string identifier (see: Charmod [1] and Charmod-Norm [2]) are considered "the same" or not. As currently written, different UTF-8 byte sequences are considered distinct.

We would suggest that identifiers that use distinct code point sequences are considered distinct (that is, that you are what we call a "non-normalizing Specification"), which suggests that you include at least a health warning about the dangers of using different character sequences.

Particularly: and
Comment 1 Simon Pieters 2015-04-21 08:16:40 UTC
I agree with the comment. It doesn't only apply to cue identifiers (also e.g. voices, classes, cue data, etc.). Maybe we can add a new subsection under Conformance?

Unicode normalization

This specification does not normalize Unicode text as part of its processing requirements.

Example: A cue with the identifier consisting of the character U+212B ANGSTROM SIGN will not match a selector targeting a cue with an ID consisting of the character U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE.
Comment 2 Silvia Pfeiffer 2015-06-08 12:17:06 UTC
I've prepared
Comment 3 Addison Phillips 2015-07-27 01:11:32 UTC
The text in the pull has the right intention, but it has a serious flaw in it. It says:

This specification requires that Unicode text must not be normalized.

I think you mean to say something more like:

Implementations of this specification MUST NOT normalize Unicode text during processing.
Comment 4 Philip J├Ągenstedt 2015-08-04 11:59:15 UTC was merged on June 10, are any further changes needed?
Comment 5 Silvia Pfeiffer 2015-08-09 09:55:24 UTC
I've made the change suggested by Addison, see
Comment 6 Silvia Pfeiffer 2015-10-01 20:56:12 UTC
Comment 7 Addison Phillips 2015-11-23 18:37:35 UTC
Satisfied by this change.