Keyboard Schema bump for v46

- Can you complete the review of the commits on this ticket, and if there are any issues file a ticket for CLDR 46.1 for us to discuss.

- Which ticket is for the life-cycle discussion target v47?

Circling back from today’s CLDR/ICU design meeting:

1. Need to document that anything with conformsTo=x must conform to version (x+1), etc.

2. Document that sample data in v46 has conformsTo=45 because the sample does not require data or schema from a later version.

   1. Document in sample

   2. Document in release notes

3. Steven to make this change in 46, and add v47 ticket for life-cycle discussion.

Suppose we have a set of layouts that conform to version 45. In version 47, a feature X is added to the schema. Are all of the layouts changed to conform to version 47, thereby becoming unusable on version 45? Or are just those that use feature X? — that is, just those that require feature X?

No, the layouts (in the CLDR repository) would not be changed to conform to version 47. They could remain at 45.

Is there the presumption that if something works on version 47 that it also works on all previous versions?

• The spec is forward compatible, so something that works on v45 can be used on later data files.

• Backwards compatibility, an older keyboard can be built with a newer version of the spec.

And how does this relate to the “version numbers in the data and sample files”?

I think that the sample files could remain at 45.

The purpose of these data files is for interchange (somewhat different from how other locale data is used), so I would think that we would expect to have a lot of files around “previous” CLDR versions that don’t need to be updated.

I would also expect that new files as authored would use the lowest possible version number, even years into the future.

Also, thinking about it, I don’t think there’s a value to the keyboard number being unrelated to CLDR, I think that it is useful to keep the same number because it’s then tied to a single release, and no ‘mapping table’ needs to be kept in tooling (and mentally).

CLDR release notes could just say there’s no change, and the latest conformsTo is still 45 (as of 46). I think the spec should do a better job of describing all of this.

(Discussed w/ )

Sounds reasonable

I think we need to dig into how conformsTo is supposed to work in practice. I took a look at this, and found:

• Layouts have version metadata to indicate their specification compliance versi​​on number, such as 45. See cldrVersion.

This looks way too coarse.

Suppose we have a set of layouts that conform to version 45. In version 47, a feature X is added to the schema. Are all of the layouts changed to conform to version 47, thereby becoming unusable on version 45? Or are just those that use feature X? — that is, just those that require feature X?

Is there the presumption that if something works on version 47 that it also works on all previous versions?

Or should conformsTo be a list, and accumulate all the versions that it conforms to? Or conformsTo changes to contain a list of featureIds?

And how does this relate to the “version numbers in the data and sample files”?

I don’t think this has been thought through enough.

perhaps we bump the conformsTo attribute to start at, say, 100?

I’d note we also have importing data from a CLDR version. That has the version of cldr releases in it.