Eliminate inconsistent use of xsd:nonNegativeInteger (#983).

[skynavga]

Closes #983.

In addition to eliminating the use of xsd:nonNegativeInteger, this PR

• eliminates use of xsd:positiveInteger
• adds notes regarding value equivalence of -0, 0, +0, etc.
• improves editorial consistency

[skynavga]

This PR modifies the normative document syntax in only the following sense: by removing certain redundant lexical representations from (1) the @length attribute of the data and chunk element types and (2) the @size attribute of the isd:isd element type. In particular, the following redundant lexical representations are excluded (for use by the above attributes) by this change:

• the use of -0 as a lexical alias for 0
• the use of + as sign indicator

In the editor's opinion, this change is of a zero or near-zero risk nature due to (1) the early state of industry roll-out of TTML2, particularly the features associated with these element types, and (2) the extremely unlikely possibility that any author has gone out of their way to use any of these redundant lexical representations when their canonical form (without any sign indicator) would suffice.

All other changes in this PR are of an editorial nature and have no conformance impact.

[nigelmegitt]

In general I prefer to make use of native XSD-defined types where possible, so in that sense changing from xsd:nonNegativeInteger to xsd:string seems like the wrong direction, but I'd like to discuss this to understand the motivation better. Adding an agenda label.

[css-meeting-bot]

The Timed Text Working Group just discussed Eliminate inconsistent use of xsd:nonNegativeInteger (#983). w3c/ttml2#1135.

The full IRC log of that discussion

<nigel> Topic: Eliminate inconsistent use of xsd:nonNegativeInteger (#983). w3c/ttml2#1135
<nigel> github: https://github.com/w3c/ttml2/pull/1135
<cyril> rrsagent, pointer
<RRSAgent> See https://www.w3.org/2019/08/01-tt-irc#T15-15-46
<nigel> Nigel: I added this to the agenda to discuss why we would move away from XSD defined types because generally
<nigel> .. speaking I feel we should use XSD defined types where they meet our needs.
<cyril> scribe: cyril
<cyril> nigel: this is your proposal glenn
<cyril> ... the first part is about the motivation
<cyril> ... the issue says there is non-consistency
<cyril> ... and the internal type does permit "-0"
<cyril> ... the consistency is a bit of a problem
<cyril> glenn: the introduction of xsd nonNegative in 3 places
<cyril> ... the data @length, chunk @length, and isd @size
<cyril> ... was an oversight from my side
<cyril> ... I failed to record that we had a non-negative-integer
<cyril> ... if you look at TTML2 1st
<cyril> ... you'll find 17 matches on <digit+>
<cyril> ... one of them is the definition of non-negative-integer
<nigel> q+ to note that in some places allowing the sign in numbers would be nonsensical, like in RGB values
<atai2> q+
<cyril> ... the only reason that we might want to have the xsd nonNegative is if we want +0 and -0 and +X be equal to X
<cyril> ... there is no reason to allow +0 or -0
<cyril> ... when we have a perfectly good type used in 17 places
<cyril> ... the other item is the introduction of xsd positiveInteger on the @version on isd
<cyril> ... in the text of the specification it already says the value must be greater than 0
<cyril> ... like repeatCount
<cyril> ... or numerator and denominator and framerate ...
<pal> q+
<cyril> ... we should use the same mechanism
<cyril> ... I checked in today a series of test
<cyril> ... based on the proposed change
<cyril> ... I don't see a risk of making this non-backwards compatible change
<cyril> ... I'm very confident it's going to affect anybody
<cyril> s/it's going/it's not going/
<cyril> nigel: I did a quick scan
<cyril> ... and in the place where the internal type is used, it would make no sense to use the xsd type
<nigel> ack ni
<Zakim> nigel, you wanted to note that in some places allowing the sign in numbers would be nonsensical, like in RGB values
<cyril> ... although I like the idea of using xsd types, I'm happy to make this change
<nigel> ack atai
<cyril> atai2: I want to understand the change
<cyril> ... so it's replacing a type with a more relaxed type
<cyril> ... that would increase the number of false positive during validation
<cyril> nigel: we add pattern constraints on some xsd strings
<cyril> ... maybe we could do that here too
<cyril> glenn: if we remove the optional sign, it's restricting the number of lexical representations, no increasing it
<cyril> ... one of the recent commit was to add more pattern
<cyril> ... I agree the current schema had been a bit inconsistent in that regard
<cyril> ... but I note that the schema is not normative
<nigel> q?
<cyril> ... my intent in this PR is to make things a bit more consistent
<nigel> ack pal
<cyril> pal: do these changes make TTML closer to CSS?
<cyril> glenn: none of these attributes are in the domain of CSS, they are not properties
<nigel> q?
<cyril> pal: so I don't have a strong opinion
<cyril> nigel: any objection to go ahead with this change?
<cyril> ... hearing none, let's proceed
<cyril> glenn: I would appreciate your final review nigel
<cyril> ... like missing pattern

[skynavga]

@nigelmegitt in none of these cases is there an issue to file, since the value of the attribute only includes <non-negative-integer> as a sub-component of its overall syntax, and its overall syntax requires use of xs:string (or some more general type) due to the presence of other syntactic components; e.g., tts:zIndex is typed as <integer> which includes an optional sign component, tts:repeatCount may have the value indefinite, etc.