Improve interoperability of non-negative-real and xs:decimal.

[skynavga]

As presently defined in §10.3.27, non-negative-real includes .0 and 0.0, but does not include 0. This creates an interoperability problem with the use of xs:decimal [1] in the schema for tta:gain and tta:pan. There is no reason we should exclude 0., so I propose we change the definition of non-negative-real to the following:

non-negative-real
  : <digit>* "." <digit>+
  | <digit>+ "."

[1] https://www.w3.org/TR/xmlschema-2/#decimal

[skynavga]

In double checking on TTML1, I see that the original syntax for non-negative-real, which excludes real numbers such as 0., is also present in TTML1 1e, 2e, and 3e, where it is used to support non-integer length values. Therefore, making this proposed change in TTML2 would effectively be an extension to TTML1 syntax, but it could be handled by adding #length-real-version-2 and adding this new designator to #length-version-2.

[skynavga]

Address https://github.com/w3c/ttml2/issues/943#issuecomment-408919164 in https://github.com/w3c/ttml2/commit/2bc285534001286cb9471b9b004e31d49b77ac91.

[skynavga]

Note further that, if we do not adopt the above proposals, then we need to change the schema datatype for tta:gain and `tta:pan from xs:decimal to xs:string in order to effectively detect the (now) invalid value expression 0.. The reason for this is that if xs:decimal is used, then the expression 0. is interned (without error) as a BigDecimal by JAXB, after which point it is impossible to distinguish between a valid original value of, say 0.0, and the invalid value 0..

[nigelmegitt]

This seems to be outside the review scope for the CfC; rather than making a substantive change now during the CfC period I'd prefer to defer this to a 2nd Ed.

[skynavga]

Deferring to consideration under ttml.next.

[skynavga]

Removing ttml.next, leaving here for ttml2 2e processing.

[css-meeting-bot]

The Timed Text Working Group just discussed Improve interoperability of non-negative-real and xs:decimal. ttml2#943.

The full IRC log of that discussion

<nigel> Topic: Improve interoperability of non-negative-real and xs:decimal. ttml2#943
<nigel> github: https://github.com/w3c/ttml2/issues/943
<cyril> nigel: this issue is about allowing zero point to be valid
<cyril> ... it is not at the moment
<cyril> ... glenn's proposal is to permit it
<cyril> ... there is a PR for this
<cyril> glenn: I restarted the original PR that had been done last year
<cyril> ... I updated based on the current master
<cyril> nigel: this means that a previous non-conformant document would become conformant
<cyril> glenn: technically yes
<cyril> ... but it was never the intention to make that non-conformant
<nigel> q?
<nigel> -> https://www.w3.org/TR/xmlschema-2/#decimal xs:decimal definition
<cyril> cyril: is '0.' allowed in xs:decimal?
<cyril> cyril: it seems that it is allowed according to section "3.2.3.1 Lexical representation"
<cyril> nigel: but the fact that the . is the last character is a bit confusing
<cyril> gkatsev: but it says that trailing 0 are optional
<nigel> q+
<cyril> glenn: we changed the schema since then to use xs:string
<cyril> ... that change was based on the comment of July 21, last year
<nigel> q?
<cyril> ... we just need to widen the expression for non negative real
<cyril> nigel: this change makes non negative real, the + becomes a *?
<cyril> glenn: no it adds a new line
<cyril> ... you need the full stop to denote it's a real number
<cyril> nigel: ok, it makes sense
<cyril> ... the idea of making non negative real coincident with xs:decimal makes sense
<cyril> ... it makes it easier to write the schema
<cyril> ... seems like a good change to me
<cyril> cyril: is it affecting only gain and pan?
<cyril> nigel: a lot of things
<cyril> ... lengths, gain, pan, ...
<cyril> ... pitch, percentage uses number
<cyril> ... a lot of things would be affected by this
<cyril> pal: I'm looking at ttval
<cyril> ... so now non-negative real always has a dot
<cyril> ... but not a dot by itsefl
<cyril> s/itsefl/itself/
<cyril> nigel: it's good to look at implementation
<cyril> ... just checking EBU-TT impl, 1. would not match, but 1.0 would
<cyril> pal: it seems ttval would reject 0. but I need to check
<cyril> nigel: it might make some existing implementations non conformant
<cyril> ... I'm beginning to think it's a problem
<cyril> glenn: there is no requirement to backport it to TTML1
<cyril> ... it would potentially make validation tools not implementing 2nd ed more restrictive
<cyril> ... not sure what the roll out status of TTML2 in the industry
<cyril> ... but that would improve the status of interop
<cyril> nigel: that would be a change for IMSC 1.1 also
<cyril> cyril: I would say we shouldn't do syntactic changes unless it's broken
<cyril> pal: if we have several such changes, we could accumulate them and wait
<cyril> ... it would make it easier to include this one
<cyril> glenn: I'm not sure I agree that it's a breaking change
<cyril> nigel: it's not a document breaking change, but an implementation breaking change
<cyril> cyril: I think people should look at their implementations and we can take a decision based on that
<cyril> nigel: if this would be the only syntactical change, then it might not be worth
<cyril> glenn: we already approved some changes
<cyril> cyril: it would be good to have a list of those
<cyril> glenn: we changed the content body to add audio
<cyril> nigel: summary: group to study implementation impact and add review comments
<cyril> pal: and if we do it, we should have a test for that

[skynavga]

Marking this issue as a bug since the omission of support for non-negative real numbers with a lexical representation of <digit>+ "." was an oversight (since TTML1 1e).