-
-
Notifications
You must be signed in to change notification settings - Fork 36
(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
Conversation
I'll be happy to wait for #420 to land before rebasing and updating this PR. In the meantime, let's discuss naming: is |
I think there's a choice we ought to make regarding the DTD part of the registry:
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 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 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 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 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. |
There was a problem hiding this 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
.
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" :) |
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.
a53b2dc
to
b864a99
Compare
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 pickedpattern
inregistry.dtd
because of "regex patterns", but I think we can do better than that.This PR also changes some
NMTOKEN
attributes toIDREF
, 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.