Data pipeline doc miscellaneous

[echeran]

There are comments on the Data Pipeline doc, since it already got merged. Would like to hear feedback to first determine if they merit changes.

• definition of "data version" - This definition describes the version of data as something that is "abstracted away from" the versions of the format and schema. I would think that the relationship is actually dependent on the schema, but still independent of the format. Since schema is the structure of the data, if the schema version changes, I would expect it to force the data version to change.

• Data version - To the extent that this matters or makes sense, it would be more readable if the keys delineate "key segments" differently from multi-word segments. CLDR_37_alpha1 and FOO_1_1 are parsed differently, whereas CLDR-37-alpha1 and FOO-1_1 would be unambiguous.

• Schema version / Data version - If we allow the data provider to choose which version(s)' worth of data to hold, then it's possible for a user to call data for a key+version which is not supported (maybe the version is too old/new, or the key has changed due to schema change). Do we have a description of how we handle that? We could just make it easy and return null / throw error. I suppose a data provider can be configured to fetch from an authoritative service with all versions of all data (depicted in the diagram?), which makes it a data provider decision/configuration.

[sffc]

Both the schema version and the format version are internal to the data provider. I broke them down to further emphasize that the choice of JSON, Protobuf, etc., is something we can abstract away from the schema with which we present CLDR data to the provider. From the outside, the only version the consumer should need to know or care about is the data version, which indicates how stale the data source is.

I have not proposed a data model for the data version. It doesn't have to be a string: it could be a struct, double, etc. I was showing the subtag-based string serialization as one potential string serialization to illustrate how the data versions might work. It would be worthwhile opening an issue to hammer out exactly what form the data version should take.

I haven't considered allowing the consumer to request a specific data version ("key+version"). My assumption is that the consumer generally wants the latest data version, and if they really need a specific data version, such as in a testing framework, then they should make their own data provider.

[sffc]

A few other issues I need to fix in the doc:

Subtags should be handled by the OmnICU code rather than the data provider.

That should say "Extensions", not "Subtags"

@echeran also wrote,

Should we describe the types in language-independent ways? Ex: signed 8-bit int (i8), signed 32-bit int (i32). It wouldn't preclude you from using the Rust type signature as shorthand in your communications.

I replied: I didn't intend for i8 and i32 to imply being rust-specific; I borrowed those names because they were more concise than writing out "8-bit signed integer" and "32-bit signed integer".