Constrain maximum value of @length on data element.

[skynavga]

For data element, specify that @length must fit in 32-bit signed integer; or specify this under #data feature definition.

[nigelmegitt]

What's the motivation for this @skynavga ? It looks like it would impose an implementation constraint on the specification.

[skynavga]

As it is currently defined, support for #data (and #chunk) may be read as requiring an implementation to make use of unbounded (arbitrary precision) integers to represent the @length value. In other contexts of the specification, we have established minimum implementation requirements, e.g., #color requires support for only 16 colors. In the present context, it appeared to me that a 32 bit signed integer should be adequate for the total length of a data embedding. However, I don't have a strong position on this so I would be willing to forego such an explicit minimum support limit (I note that we do not specify such limits in many other cases).

[palemieux]

See also the prior discussion at w3c/ttml1#307

Seems like this has the potential to be a tremendous amount of work.

[nigelmegitt]

I've added this to the agenda for tomorrow's call, to see if we have consensus to close with no change.

[css-meeting-bot]

The Timed Text Working Group just discussed Constrain maximum value of @length on data element. ttml2#1023, and agreed to the following:

• RESOLUTION: we close issue 1023 with no change

The full IRC log of that discussion

<nigel> Topic: Constrain maximum value of @Length on data element. ttml2#1023
<nigel> github: https://github.com//issues/1023
<cyril> glenn: the only place where it might be useful to have a constraint is when you have base64 data
<cyril> ... you could have an infinitely long document
<cyril> ... so I was proposing to limit that to 4GB
<cyril> cyril: Isn't this an application-level constraint
<cyril> nigel: yes
<cyril> glenn: application can do that so probably no need to put a constraint in the spec
<cyril> ... there is a difference in code
<cyril> ... if you are writing a validator, you cannot use a 32 bit integer for the size
<cyril> nigel: I propose to close the issue with no change
<cyril> ... any objection
<cyril> RESOLUTION: we close issue 1023 with no change

[skynavga]

Noting that taking no action may require implementations to use arbitrary precision number representations to represent @length values greater than 2^32, I concur that no further action is required and therefore withdraw this issue.