Skip to content

(registry.dtd) Rename pattern to validationRule #435

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 14, 2023

Conversation

stasm
Copy link
Collaborator

@stasm stasm commented Jul 23, 2023

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
Copy link
Collaborator Author

stasm commented Jul 23, 2023

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/>)?

@stasm stasm requested review from aphillips, eemeli and mihnita July 23, 2023 22:30
@eemeli
Copy link
Collaborator

eemeli commented Jul 24, 2023

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.

Copy link
Collaborator

@eemeli eemeli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@stasm
Copy link
Collaborator Author

stasm commented Jul 24, 2023

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
Copy link
Member

@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.

@aphillips aphillips added the functions Issue pertains to the default function set label Jul 24, 2023
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 unicode-org#407 (comment).

This PR doesn't address the main question of unicode-org#407, however. It's only concerned with renaming `pattern` to prevent confusion.
@aphillips aphillips merged commit e3c6025 into unicode-org:main Aug 14, 2023
@stasm stasm deleted the validation-rules branch August 16, 2023 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
functions Issue pertains to the default function set
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants