Tolerate Types Register entries with Type Size values not supported by Reg-XML

[thomasheritage]

Types entries with a Type Kind of "Integer" are permitted to have a Type Size that is any integer value greater than zero. However, Reg-XML only supports a limited selection of values.

Currently regxmllib throws an Exception if it encounters an Integer Type entry with a Type Size not supported in Reg-XML.

Instead, regxmllib should report an error for the Type entry and ignore it.

This same approach should also be applied to the "Float" Type Kind for consistency.

Note: this is comparable to #119

Note: this issue affects the processing of an active Registers Submission that defines a 48-bit Integer Type

[palemieux]

Note: this issue affects the processing of an active Registers Submission that defines a 48-bit Integer Type

The submitter should be informed that this is incompatible with existing implementation and that a 64-bit integer type should be used instead.

[thomasheritage]

My understanding is that this is not for use in MXF Header Metadata. It will be used in a KLV data stream that incorporates IEEE PTP timestamps (which use a UInt48 for the "seconds" field).

[palemieux]

@thomasheritage Understood. I ran into a similar issue recently. Would this be a good opportunity to consistently label those entries that are intended for use in MXF Header Metadata? It would avoid having to create/maintain special cases.

[thomasheritage]

I believe addressing this issue is a simple fix per #147 – this simply updates the error handling behaviour of regxmllib in-line with previous changes e.g. per #119. So, I don’t think there will be any special cases to create.

This is one of various cases where the Registers support a wider set of entries than Reg-XML and so regxmllib has to filter out entries that are not supported.

Would this be a good opportunity to consistently label those entries that are intended for use in MXF Header Metadata?

That's an interesting idea and could help Submission authors. Perhaps something to consider separately given the amount of work involved? Some considerations:

• That seems to basically move the (largely existing) filtering logic from regxmllib to the Registers tooling (although presumably it would still be needed in regxmllib anyway to be defensive when importing entries).
• The Registers tools would need to (help to) ensure that all existing and new entries are labelled appropriately (including special cases i.e. entries which behave differently in MXF).
• There are some edge cases where Reg-XML and MXF Header Metadata differ in terms of what they support.
• Perhaps this would use the Applications field in the Registers – we would need to work out what to do with existing data in that field.

[thomasheritage]

Thanks for the swift resolution. This is built and deployed on the Registers Website, resolving the problem with the affected Registers Submission.