You're missing at least one production here, unless you think iso8601 covers that? (using a different syntax??)

Is there some reason we can't reference XMLSchema directly?

In case you're referring to the :datetime operand, changing its validation rule here would be scope creep.

To refer to external specs, we need language for how to do that, and that's not currently supported by registry.dtd.

Agreed. xsd recommends itself, except I'm not sure how compatible the number types are with JSON number (in fact, I'm sure they aren't compatible)

I suspect we should make the registry's format completely unpromised in Tech Preview--even the use of XML. The normative bits are the default registry prose right now anyway. Let's solve this good and proper--and not over the weekend. I don't think anyone's implementation depends on the XML file now. We shouldn't encourage anyone to depend on it being any particular way in the future.

Thoughts?

Are you going to describe in any amount of detail what the difference is between these four styles?

No. 😉 🙈

This is what CLDR is for :-)

On a higher level, we do not prescribe any output from any function. An implementation is free to implement options in anyway that it sees fit, including doing nothing at all. They just have to accept all of the options and values that they are required to accept by the spec.

They can also extend the options as they see fit (we recommend using namespaced options when doing so).

User will complain if the options don't work or work badly, but that's a problem for the implementer, not MFv2.

This general strategy seems problematic. It means that whatever ICU implements will become the de-facto standard behavior. If ICU4X or ECMA or Ruby or Scala implement a different semantic meaning for the same formatting options, users will file bugs that their behavior is different than on the canonical ICU implementation, even if those other implementations are spec-compliant. It is the spec's role to prevent semantic differences between implementations.

This general strategy already exists. FWIW, different versions of CLDR change what these shorthands mean or what specific data values are. Different locales handle these differently. CLDR changes formatting details all the time.

I tend to tell developers not to worry about--or depend on--the specific output in any specific locale.

But this is one reason why I love date skeletons and actively told users for the past five or eight years never to use the shorthand keywords. Tell the system what you want and DateTimePatternGenerator will build you the appropriate pattern in every locale. The translators don't have to mess with it and you'll never have that weird bug in some language in which short has some non-numeric gunk in it or whatever. I would submit that a "medium" date has no semantic meaning (the fact that you want me to describe it says that to be true!), while skeleton=EEEyyyyMMMd (<= not meant to be a medium date, eh?) says what I want and the results will contain no surprises.

I think I read into a lot of your comments this week a disconnect between MFWG's approach to formats and your expectations. MF2 does not implement any formatting at all. It delegates the formatting. Our options are user-facing and exist to let developers/translators communicate with the runtime what their formatting needs are. I hear the number or date formatter implementer in you--and value those comments hugely for keeping us honest. Many of our implementers, though, won't own the Intl equivalent code. They'll call platform I18N APIs using the options we provide (appropriately mapped) and their implementations should not require them to mirror ICU76 or a specific Intl version exactly. They can depend on system APIs for numbers and dates, at least mostly, I hope.

So... in this case, the keywords are widely recognized and CLDR even provides for them. But if Rust or Ruby want to impute different meanings or slightly different implementations, again, user's will complain if the results are wacky or wholly unexpected--or if they like the innovation, they'll complain to Annemarie et al about CLDR! Even CLDR has bugs in these cases.