(registry.dtd) Rename pattern to validationRule

[stasm]

We already use pattern to describe a sequence of text and placeholders in the message body. Let's not overload it with another, validation-related meaning. I had picked pattern in registry.dtd because of "regex patterns", but I think we can do better than that.

This PR also changes some NMTOKEN attributes to IDREF, as noticed by @eemeli in #407 (comment).

This PR doesn't address the main question of #407, however. It's only concerned with renaming pattern to prevent confusion.

[stasm]

I'll be happy to wait for #420 to land before rebasing and updating this PR. In the meantime, let's discuss naming: is validationRule the right choice for both the element (<validationRule id=positiveInteger regex=.../>) and the idref attribute (<option name=... validationRule=positiveInteger/>)?

[eemeli]

I think there's a choice we ought to make regarding the DTD part of the registry:

1. Do we want it to act as a single source of truth and be usable by linters and other tooling?
2. Or do we want it to be a minimal core that's supported by text?

When considering this, my preference is tending towards the latter as that's much easier and more realistic. I'd really rather not try and figure out how in the DTD we can express requirements like "The :number function accepts as input a finite numerical value". These are much easier expressed in prose, which we may make equally binding.

Furthermore, there's the question of conformance: Is it ok for an implementation to emit an error and potentially use fallback resolution when it's passed an option that's satisifes a pattern or validationRule but which it can't handle? For a specific example, what's allowed behaviour for a :number formatter when it's given minimumFractionDigits=99?

My preference here would be for us to define e.g. options baskets that a conforming implementation must not complain about, but not restrict what happens for other values. So with the example above, I think we can and should say that minimumFractionDigits must accept values in the range 0..20, but allow an implementation to go beyond that.

With this approach, the registry DTD could by itself be used to validate a message, but not define the shape of the parameters or arguments that its formatting function ought to be called with. One aspect that we might want to add is the capability to say something like, "The resolved value of a :number can be used as a :plural input."

All in all, that's a long-winded way for me to say that I think limiting literal value definitions to values + regex pattern is fine, and what's not expressible as such ought to still be supportable by an implementation.

[eemeli]

Regarding this PR specifically, as you asked for a review: Please (eventually) also update registry.md.

[stasm]

Regarding this PR specifically, as you asked for a review: Please (eventually) also update registry.md.

I marked the PR as draft because I'd like to get feedback on the proposed naming before making other related changes. I wish GitHub called review requests on draft PR "feedback requests" :)

[aphillips]

@stasm I agree with the change you propose here. We need to be rigorous about our terminology use to avoid confusion.

@eemeli Let's discuss the other topics in an issue or issues.