-
-
Notifications
You must be signed in to change notification settings - Fork 36
Define function composition for :number and :integer values #823
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
@@ -422,6 +422,12 @@ The following options and their values are required to be available on the funct | |||
- `maximumSignificantDigits` | |||
- ([digit size option](#digit-size-options)) | |||
|
|||
If the _operand_ of the _expression_ is an implementation-defined type, | |||
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_, | |||
it can include option values. |
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.
"can" reads like "MAY", but the other suggested text reads like these "MUST" exist (that is, must be permitted). Perhaps:
it can include option values. | |
it includes any _option_ values of the _expression_. |
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.
See the thread above; the language currently covers numerical types that are not resolved values. With that context, changing this to "it includes" seems a bit wrong?
@@ -422,6 +422,12 @@ The following options and their values are required to be available on the funct | |||
- `maximumSignificantDigits` | |||
- ([digit size option](#digit-size-options)) | |||
|
|||
If the _operand_ of the _expression_ is an implementation-defined type, | |||
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_, |
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.
We are defining :number
and :integer
here. Is "such as" needed?
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.
The "such as" is making sure that the resolved value type is included in the "an implementation-defined type" set of possibilities.
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.
Presumably it would be that, otherwise the result would be bad operand?
Why does the operand need to be of the implementation-defined variety? Aren't option values also applicable to, for example, accepted literal values?
{-1.234 :number maximumFractionDigits=2 signDisplay=always}
Why wouldn't the options "stick to" the value?
Are you trying to say that the resolved value input to the function might be influenced by ("include") the options previously applied? Should we be more direct?
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_, | |
The _resolved value_ of the _operand_ of an _expression_ includes any of the | |
above _options_ applied to the value. |
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.
I'm trying to follow our practice of not defining exactly what a "number" type is, while allowing for some implementation-defined number types, such as the resolved value coming from a :number
annotation, to contain options within the value of the operand.
So this is covering each of the following use cases:
-
{$x :number}
where in a JS context that could be formatted with{ x: BigInt(42) }
, i.e. using a language-specific numerical type. -
{$y :number style=currency}
where in a JS context that could be formatted with
{ y: Object.assign(new Number(42), { options: { currency: 'EUR' } }) }
,
i.e. an object that carries both a numerical value and a bag of options. -
.local $z = {42 :number notation=compact} {{{$z :number compactDisplay=long}}}
so that in the placeholder the options of the operand$z
can be combined with the expression options.
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.
Right. We're on the same page technically. I'm bikeshedding the language.
I think the challenge for me is that "implementation-defined type" appears to exclude some values (such as literal representation). It's not clear to me if we require the implementation to resolve it to an implementation-defined type. For example, we say:
The operand of a number function is either an implementation-defined type or a literal whose contents match the number-literal production in the ABNF. All other values produce a Bad Operand error.
... but we don't say that the literal becomes one of the implementation-defined types (although it might).
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.
The thing is, though, that a literal representation of a number cannot include option values within the operand. The annotation of a literally represented number can absolutely have options, but its operand cannot.
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.
What about transitivity?
.local $a = {42 :number signDisplay=always}
.local $b = {$a :number minimumFractionDigits=1}
{{{$b}'s operand is an annotated literal??}}
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.
In that example, when resolving the expression defining the value of $b
, its operand is a resolved value, an implementation-defined type. The numerical value contained in that implementation-defined type is the number 42, and it includes a bag of resolved options { signDisplay: 'always' }
.
When resolving the value of $b
or formatting the placeholder {$b}
, the only impact that the literal origin of the value should have is that the fallback string that's used for it is |42|
, and not e.g. $x
.
@@ -538,6 +551,18 @@ function `:integer`: | |||
- `maximumSignificantDigits` | |||
- ([digit size option](#digit-size-options)) | |||
|
|||
If the _operand_ of the _expression_ is an implementation-defined type, | |||
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_, | |||
it can include option values. |
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.
ibid.
@@ -605,6 +630,14 @@ MUST be multiplied by 100 for the purposes of formatting. | |||
|
|||
The _function_ `:integer` performs selection as described in [Number Selection](#number-selection) below. | |||
|
|||
#### Composition | |||
|
|||
When an _operand_ or an _option_ value uses a _variable_ annotated, |
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.
"uses" seems wrong to me?
When an _operand_ or an _option_ value uses a _variable_ annotated, | |
When an _operand_ or the value of an _option_ consists of a _variable_ previously annotated, |
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.
This language was suggested by @stasm in #814 (comment), and is currently the same across the three PRs. Would it be ok to not nitpick on this now, and iterate on the exact language once these changes have first landed?
Co-authored-by: Addison Phillips <addison@unicode.org>
spec/registry.md
Outdated
|
||
When an _operand_ or an _option_ value uses a _variable_ annotated, | ||
directly or indirectly, by a `:number` _annotation_, | ||
its resolved value contains an implementation-defined numerical value |
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.
Would it be more precise to say that the getValue()
method of its resolved value returns an implementation-defined numeric value? (Assuming the definition of resolved values in #728.)
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.
Yes.
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Eemeli Aro <eemeli@mozilla.com>
Co-authored-by: Eemeli Aro <eemeli@mozilla.com>
* Create notes-2024-08-19.md * Accept attributes design & remove spec note (#845) * Accept attributes design & remove spec note * Disallow duplicate attribute names (closes #756) * Add link to contextual options PR * Add more prose to tag example text Co-authored-by: Addison Phillips <addison@unicode.org> * Mention attribute validity condition in the **_valid_** definition --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Update selection-declaration design doc based on mtg / issue discussion (#867) * Add tests for pattern selection (#863) * Add tests for pattern selection * Add missing errors * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Add Duplicate Variant to table in test/README.md (#861) * Add new selection-declaration alternative: Require annotation of selector variables in placeholders (#860) * Add new selection-declaration alternative: Require annotation of selector variables in placeholders * Improve examples * Switch example order * Update the stability policy (#834) * Update the stability policy Based on discussion in the 2024-07-22 call and in PR #829, update the stability policy. * A deeper, more thorough rewrite - Standardizes the phrasing completely. - Moves all potential future changes (which are not, after all, stability policies) to an "important" block - Removes duplication - Separates functions, options, and option values into separate guarantees - Clarifies the note about formatting changing over time * Update spec/README.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update spec/README.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * remove well-formed * Update spec/README.md --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Refine error handling text (#816) * Refine error handling text * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Update fallback text * Turn bullet point list into paragraphs * Be more mighty Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Create notes-2024-08-26.md * Select "Match on variables instead of expressions" for selection-declarations (#824) * Select "Match on variables instead of expressions" for selection-declarations * Add hybrid option to selection-declaration.md (#870) * Add hybrid option to selection-declaration.md * Update selection-declaration.md fixed glitch in original edit * Update selection-declaration.md * Apply suggestions from code review Fixing typos Co-authored-by: Addison Phillips <addison@unicode.org> * Update selection-declaration.md * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update selection-declaration.md --------- Co-authored-by: Mark Davis <mark@unicode.org> Co-authored-by: Addison Phillips <addison@unicode.org> * Fix "Allow immutable input declarative selectors" example (#874) * Update README.md (#875) * Update README.md * Update README.md * [DESIGN] Update bidi design document to show proposed design (#871) * [DESIGN] Update bidi design document to show proposed design The design I actually think we should adopt is the "hybrid approaches" one. This is a necessary first step on the highway to UAX31 compliance and I think is responsibly contained/managed. It is a hybrid approach, in that it permits testable strict implementations to be created (particularly for message serialization). This PR consists of moving text around. I added one "pro" to one option also. * Address comments * Miscellaneous test fixes (#862) * Add missing expected bad-selector errors * Fix expected parts for unsupported-statement test * Add a few new tests for leading-whitespace and duplicate-variant * Add tests for escaped-char changes made in #743 * Fix tests for attributes with variable values * Update contributing and joining info (#876) * Update contributing and joining info * Update README.md * Update CONTRIBUTING.md * Restore CLA copy * Clarify error & fallback handling (#879) * Clarify error & fallback handling * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Select last rather than first attribute * Drop mention of "starting with Pattern Selection" * Attributes can't change the formatted output * Use "nor" instead of "or" regarding attribute restrictions --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Clarify rule selection (#878) * Clarify rule selection Fixes #868 This adds normative SHOULD language to using CLDR plural and ordinal data, which was intended originally. - clarifies that keyword selection follows exact match - clarifies the purpose of rule-based selection - makes non-CLDR-based implementation permitted * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * [DESIGN] Maintaining the Standard, Optional and Unicode Namespace Function Sets (#634) * Design doc to capture registry maintenance * Update maintaining-registry.md * Update exploration/maintaining-registry.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update exploration/maintaining-registry.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Add user stories, small updates to RGI * Update exploration/maintaining-registry.md * Adding additional detail * Remove machine readable registry; update prose * Update maintaining-registry.md * Further development work * Update to change format and naming Per the 2024-08-19 call, we decided to switch towards a specification-per-function model, with statuses. This commit includes the initial set of changes to try and implement this. * Address some comments. --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> * Create notes-2024-09-09.md * Fix a typo in an example (#880) The upcoming work to implement resolved value might make this patch unnecessary or obsolete, but fixing the typo (missing `{`/`}` around the variable in the pattern) just in case * Remove forward-compatibility promise and all reserved & private syntax (#883) * Remove forwards compatibility from stability guarantee * Drop reserved statements and expressions * Drop private-use annotations * Update tests * Clarify that deprecation is not removal * Match on variables instead of expressions (#877) * Match on variables instead of expressions * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Apply suggestions from code review * Add missing test changes noticed during implementation * Empty commit to re-trigger CLA check --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Create notes-2024-09-10.md * Add bidi support and address UAX31/UTS55 requirements (#884) * Add bidi support and address UAX31/UTS55 requirements Adds the bidi strong marks ALM, RLM, and LRM plus the bidi isolate controls LRI, RLI, FSI, and PDI to the syntax. Formally defines optional vs. non-optional whitespace. Non-optional whitespace must include at least one whitespace character. Optional whitespace may contain only bidi marks (which are invisible) * Update syntax.md including text from previous PR * Repair the guidance on strongly directional marks Include ALM and better specify how to use the marks. * Fix formatting of the "important" * Add bidi characters to description of whitespace. * Permit bidi in a few more places Add optional whitespace at the start of `variant` Add optional whitespace around `quoted-pattern` These changes result in allowing bidi around keys and quoted patterns as intended. * Update syntax.md ABNF * Update formatting.md - Add a note about the difference between formatting and message syntax. - Clarify the sentence about message directionality. * Address comment about name/identifier * Address comments related to bidi in `name` * Fix variable's location * Address comment about the list of LRI/PDI targets * One character typo :-P * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Address comments about rule R3a-1 * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Address comment about U+061C * Change [o]wsp => `o` or `s` * Match syntax spec to abnf * Remove * * Update syntax.md * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update syntax.md * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Specify `bad-option` for bad digit size option values (#882) * Specify `bad-option` for bad digit size option values Fixes #739 * adopt 'non-negative integer' * Create notes-2024-09-16.md * Address name and literal equality (#885) * Address name and literal equality This change defines equality as discussed in the 2024-09-09 teleconference in the following ways: - It defines _name_ equality as being under NFC - It defines _literal_ equality as explicitly **not** under NFC - It moves _name_ before _identifier_ in that section of text to avoid a forward definition. Note that this deviates from discussion in 2024-09-09's call in that we didn't discuss literals at length. It also doesn't discuss non-name/non-literal values, which I'll point out are limited to ASCII sequences such as keywords. * Typo fix * Add a note about not requiring implementations to actually normalize * Implement changes dicussed in 2024-09-16 call. - Make _key_ require NFC for uniqueness/comparison - Add a note about NFC - Make _literal_ **_not_** define equality - Make text in _name_ identical to that in _key_ for consistency * Update formatting.md to include keys in NFC * Address comments * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update list of normative changes during the LDML45 period (#890) * Fix typos in data-model-errors tests (#892) Fix #886 * Update note on exact numeric match for v46 (#891) Addresses #887 Non-normative changes to the notes specifically part of LDML46 * Fix attribute value to be literal (#894) Fixes #893 * Create notes-2024-09-30.md * Add Resolved Values and Function Handler sections to formatting (#728) * Add Resolved Values section to formatting * Apply suggestions from code review * Apply suggestions from code review * Apply suggestions from code review Co-authored-by: Tim Chevalier <tjc@igalia.com> * Linkify "resolved value" * Add some examples & explicitly allow wrapping input values * No throw, only emit Co-authored-by: Tim Chevalier <tjc@igalia.com> * Add section on Function Handlers, defining the term * Apply suggestions from code review * Rephrase initial resolved value definition * Update spec/formatting.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update resolved value definition again Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Addison Phillips <addison@unicode.org> * Define function composition for :number and :integer values (#823) * Define function composition for :number and :integer values * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Add operand option priority example * Add apostrophes' Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> * Create notes-2024-10-07.md * Apply NFC normalization during :string key comparison (#905) * Apply NFC normalization during :string key comparison * Add link to UAX#15 Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Add tests for changes due to bidi/whitespace (#902) * Add tests for changes due to bidi/whitespace * Correct output * Make erroneous test a syntax error * Define function composition for date/time values (#814) * Define function composition for date/time values * Apply suggestions from code review Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> * Drop the "only" * Update spec/registry.md * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Make :date and :time composition implementation-defined --------- Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> Co-authored-by: Addison Phillips <addison@unicode.org> * DESIGN: Add alternative designs to the design doc on function composition (#806) * DESIGN: Add a sequel to the design doc on function composition This document sketches out some alternatives for the machinery provided to enable function composition. The goal is to provide an exhaustive list of alternatives. * Remove 'part 2' document and move contents to the end of part 1 * Revise introduction to reflect the changed goal * Edited for conciseness * Further edits for conciseness * Give a name to InputType and use it * Refer to motivating examples * Update function-composition-part-1.md status Per 2024-10-14 telecon * Create notes-2024-10-14.md * Add test for :integer and :number composition (#907) * Fix `:integer` option `useGrouping` values (#912) I noticed that `:integer` does not include the "never" value for the option `useGrouping`. This is a bug. * Drop syntax note on additional bidi changes (#910) Drop syntax note on addition bidi changes * Add tests for changes due to #885 (name/literal equality) (#904) * Add tests for changes due to #885 (name/literal equality) * Update test/tests/functions/string.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Update test/tests/syntax.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Update test/tests/functions/string.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Added tests for reordering and special case mapping * Add another selection test --------- Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Add u: options namespace (#846) * Move spec/registry.md -> spec/registry/default.md * Add Unicode Registry definition * Refer to BCP47, add note about only requiring normal tags * Call it a namespace * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Fix test file reference Co-authored-by: Tim Chevalier <tjc@igalia.com> * Apply suggestions from code review * Update spec/u-namespace.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Add mention of functions to namespace description --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> * Define function composition for :string values (#798) * Define function composition for :string values * Update spec/registry.md as suggested by @stasm in #814 * Drop the "only" * Update text following code review comments --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Drop data model request for feedback on "name" (#909) * Allow surrogates in content, issue #895 (#906) * Allow surrogates in content, issue #895 * Grammar and typos, linkify terms, make into a note, and fix 2119 keywords Thanks Addison! Co-authored-by: Addison Phillips <addisonI18N@gmail.com> * Not using "localizable elements" Co-authored-by: Addison Phillips <addisonI18N@gmail.com> * Keep syntax.md in sync with message.abnf * Added note about surrogates to quoted literals * Moved the note about surrogates from Security Considerations to The Message * Update spec/syntax.md * Update spec/syntax.md * Italicize in a couple of places * Implemeted more (all?) feedback from review --------- Co-authored-by: Addison Phillips <addisonI18N@gmail.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> Co-authored-by: Elango Cheran <elango@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Mark Davis <mark@unicode.org> Co-authored-by: Danny Gleckler <daniel.gleckler@d2l.com> Co-authored-by: Steven R. Loomis <srl295@gmail.com> Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> Co-authored-by: Eemeli Aro <eemeli@gmail.com> Co-authored-by: Mihai Nita <nmihai_2000@yahoo.com>
* [DESIGN] Number selection design refinements This is to build up and capture technical considerations for how to address the issues raised by @eemeli's PR #842. * Update examples to match changes to syntax Also responds to the long discussion with @eemeli about significant digits by removing from the example. * Address 2024-09-16 call comments This changes the status to "Re-Opened" and adds a link to the PR. Expect to merge this imminently, although discussion on number selection remains. * Update exploration/number-selection.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update from main (#914) * Create notes-2024-08-19.md * Accept attributes design & remove spec note (#845) * Accept attributes design & remove spec note * Disallow duplicate attribute names (closes #756) * Add link to contextual options PR * Add more prose to tag example text Co-authored-by: Addison Phillips <addison@unicode.org> * Mention attribute validity condition in the **_valid_** definition --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Update selection-declaration design doc based on mtg / issue discussion (#867) * Add tests for pattern selection (#863) * Add tests for pattern selection * Add missing errors * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Add Duplicate Variant to table in test/README.md (#861) * Add new selection-declaration alternative: Require annotation of selector variables in placeholders (#860) * Add new selection-declaration alternative: Require annotation of selector variables in placeholders * Improve examples * Switch example order * Update the stability policy (#834) * Update the stability policy Based on discussion in the 2024-07-22 call and in PR #829, update the stability policy. * A deeper, more thorough rewrite - Standardizes the phrasing completely. - Moves all potential future changes (which are not, after all, stability policies) to an "important" block - Removes duplication - Separates functions, options, and option values into separate guarantees - Clarifies the note about formatting changing over time * Update spec/README.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update spec/README.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * remove well-formed * Update spec/README.md --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Refine error handling text (#816) * Refine error handling text * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Update fallback text * Turn bullet point list into paragraphs * Be more mighty Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Create notes-2024-08-26.md * Select "Match on variables instead of expressions" for selection-declarations (#824) * Select "Match on variables instead of expressions" for selection-declarations * Add hybrid option to selection-declaration.md (#870) * Add hybrid option to selection-declaration.md * Update selection-declaration.md fixed glitch in original edit * Update selection-declaration.md * Apply suggestions from code review Fixing typos Co-authored-by: Addison Phillips <addison@unicode.org> * Update selection-declaration.md * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update exploration/selection-declaration.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update selection-declaration.md --------- Co-authored-by: Mark Davis <mark@unicode.org> Co-authored-by: Addison Phillips <addison@unicode.org> * Fix "Allow immutable input declarative selectors" example (#874) * Update README.md (#875) * Update README.md * Update README.md * [DESIGN] Update bidi design document to show proposed design (#871) * [DESIGN] Update bidi design document to show proposed design The design I actually think we should adopt is the "hybrid approaches" one. This is a necessary first step on the highway to UAX31 compliance and I think is responsibly contained/managed. It is a hybrid approach, in that it permits testable strict implementations to be created (particularly for message serialization). This PR consists of moving text around. I added one "pro" to one option also. * Address comments * Miscellaneous test fixes (#862) * Add missing expected bad-selector errors * Fix expected parts for unsupported-statement test * Add a few new tests for leading-whitespace and duplicate-variant * Add tests for escaped-char changes made in #743 * Fix tests for attributes with variable values * Update contributing and joining info (#876) * Update contributing and joining info * Update README.md * Update CONTRIBUTING.md * Restore CLA copy * Clarify error & fallback handling (#879) * Clarify error & fallback handling * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Select last rather than first attribute * Drop mention of "starting with Pattern Selection" * Attributes can't change the formatted output * Use "nor" instead of "or" regarding attribute restrictions --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Clarify rule selection (#878) * Clarify rule selection Fixes #868 This adds normative SHOULD language to using CLDR plural and ordinal data, which was intended originally. - clarifies that keyword selection follows exact match - clarifies the purpose of rule-based selection - makes non-CLDR-based implementation permitted * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * [DESIGN] Maintaining the Standard, Optional and Unicode Namespace Function Sets (#634) * Design doc to capture registry maintenance * Update maintaining-registry.md * Update exploration/maintaining-registry.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update exploration/maintaining-registry.md Co-authored-by: Tim Chevalier <tjc@igalia.com> * Add user stories, small updates to RGI * Update exploration/maintaining-registry.md * Adding additional detail * Remove machine readable registry; update prose * Update maintaining-registry.md * Further development work * Update to change format and naming Per the 2024-08-19 call, we decided to switch towards a specification-per-function model, with statuses. This commit includes the initial set of changes to try and implement this. * Address some comments. --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> * Create notes-2024-09-09.md * Fix a typo in an example (#880) The upcoming work to implement resolved value might make this patch unnecessary or obsolete, but fixing the typo (missing `{`/`}` around the variable in the pattern) just in case * Remove forward-compatibility promise and all reserved & private syntax (#883) * Remove forwards compatibility from stability guarantee * Drop reserved statements and expressions * Drop private-use annotations * Update tests * Clarify that deprecation is not removal * Match on variables instead of expressions (#877) * Match on variables instead of expressions * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Apply suggestions from code review * Add missing test changes noticed during implementation * Empty commit to re-trigger CLA check --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Create notes-2024-09-10.md * Add bidi support and address UAX31/UTS55 requirements (#884) * Add bidi support and address UAX31/UTS55 requirements Adds the bidi strong marks ALM, RLM, and LRM plus the bidi isolate controls LRI, RLI, FSI, and PDI to the syntax. Formally defines optional vs. non-optional whitespace. Non-optional whitespace must include at least one whitespace character. Optional whitespace may contain only bidi marks (which are invisible) * Update syntax.md including text from previous PR * Repair the guidance on strongly directional marks Include ALM and better specify how to use the marks. * Fix formatting of the "important" * Add bidi characters to description of whitespace. * Permit bidi in a few more places Add optional whitespace at the start of `variant` Add optional whitespace around `quoted-pattern` These changes result in allowing bidi around keys and quoted patterns as intended. * Update syntax.md ABNF * Update formatting.md - Add a note about the difference between formatting and message syntax. - Clarify the sentence about message directionality. * Address comment about name/identifier * Address comments related to bidi in `name` * Fix variable's location * Address comment about the list of LRI/PDI targets * One character typo :-P * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Address comments about rule R3a-1 * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Address comment about U+061C * Change [o]wsp => `o` or `s` * Match syntax spec to abnf * Remove * * Update syntax.md * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update syntax.md * Update spec/message.abnf Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Specify `bad-option` for bad digit size option values (#882) * Specify `bad-option` for bad digit size option values Fixes #739 * adopt 'non-negative integer' * Create notes-2024-09-16.md * Address name and literal equality (#885) * Address name and literal equality This change defines equality as discussed in the 2024-09-09 teleconference in the following ways: - It defines _name_ equality as being under NFC - It defines _literal_ equality as explicitly **not** under NFC - It moves _name_ before _identifier_ in that section of text to avoid a forward definition. Note that this deviates from discussion in 2024-09-09's call in that we didn't discuss literals at length. It also doesn't discuss non-name/non-literal values, which I'll point out are limited to ASCII sequences such as keywords. * Typo fix * Add a note about not requiring implementations to actually normalize * Implement changes dicussed in 2024-09-16 call. - Make _key_ require NFC for uniqueness/comparison - Add a note about NFC - Make _literal_ **_not_** define equality - Make text in _name_ identical to that in _key_ for consistency * Update formatting.md to include keys in NFC * Address comments * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/syntax.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update list of normative changes during the LDML45 period (#890) * Fix typos in data-model-errors tests (#892) Fix #886 * Update note on exact numeric match for v46 (#891) Addresses #887 Non-normative changes to the notes specifically part of LDML46 * Fix attribute value to be literal (#894) Fixes #893 * Create notes-2024-09-30.md * Add Resolved Values and Function Handler sections to formatting (#728) * Add Resolved Values section to formatting * Apply suggestions from code review * Apply suggestions from code review * Apply suggestions from code review Co-authored-by: Tim Chevalier <tjc@igalia.com> * Linkify "resolved value" * Add some examples & explicitly allow wrapping input values * No throw, only emit Co-authored-by: Tim Chevalier <tjc@igalia.com> * Add section on Function Handlers, defining the term * Apply suggestions from code review * Rephrase initial resolved value definition * Update spec/formatting.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update resolved value definition again Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Addison Phillips <addison@unicode.org> * Define function composition for :number and :integer values (#823) * Define function composition for :number and :integer values * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Add operand option priority example * Add apostrophes' Co-authored-by: Tim Chevalier <tjc@igalia.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> * Create notes-2024-10-07.md * Apply NFC normalization during :string key comparison (#905) * Apply NFC normalization during :string key comparison * Add link to UAX#15 Co-authored-by: Addison Phillips <addison@unicode.org> --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Add tests for changes due to bidi/whitespace (#902) * Add tests for changes due to bidi/whitespace * Correct output * Make erroneous test a syntax error * Define function composition for date/time values (#814) * Define function composition for date/time values * Apply suggestions from code review Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> * Drop the "only" * Update spec/registry.md * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Update spec/registry.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Make :date and :time composition implementation-defined --------- Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> Co-authored-by: Addison Phillips <addison@unicode.org> * DESIGN: Add alternative designs to the design doc on function composition (#806) * DESIGN: Add a sequel to the design doc on function composition This document sketches out some alternatives for the machinery provided to enable function composition. The goal is to provide an exhaustive list of alternatives. * Remove 'part 2' document and move contents to the end of part 1 * Revise introduction to reflect the changed goal * Edited for conciseness * Further edits for conciseness * Give a name to InputType and use it * Refer to motivating examples * Update function-composition-part-1.md status Per 2024-10-14 telecon * Create notes-2024-10-14.md * Add test for :integer and :number composition (#907) * Fix `:integer` option `useGrouping` values (#912) I noticed that `:integer` does not include the "never" value for the option `useGrouping`. This is a bug. * Drop syntax note on additional bidi changes (#910) Drop syntax note on addition bidi changes * Add tests for changes due to #885 (name/literal equality) (#904) * Add tests for changes due to #885 (name/literal equality) * Update test/tests/functions/string.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Update test/tests/syntax.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Update test/tests/functions/string.json Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Added tests for reordering and special case mapping * Add another selection test --------- Co-authored-by: Eemeli Aro <eemeli@gmail.com> * Add u: options namespace (#846) * Move spec/registry.md -> spec/registry/default.md * Add Unicode Registry definition * Refer to BCP47, add note about only requiring normal tags * Call it a namespace * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Fix test file reference Co-authored-by: Tim Chevalier <tjc@igalia.com> * Apply suggestions from code review * Update spec/u-namespace.md Co-authored-by: Eemeli Aro <eemeli@mozilla.com> * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Apply suggestions from code review Co-authored-by: Addison Phillips <addison@unicode.org> * Add mention of functions to namespace description --------- Co-authored-by: Addison Phillips <addison@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> * Define function composition for :string values (#798) * Define function composition for :string values * Update spec/registry.md as suggested by @stasm in #814 * Drop the "only" * Update text following code review comments --------- Co-authored-by: Addison Phillips <addison@unicode.org> * Drop data model request for feedback on "name" (#909) * Allow surrogates in content, issue #895 (#906) * Allow surrogates in content, issue #895 * Grammar and typos, linkify terms, make into a note, and fix 2119 keywords Thanks Addison! Co-authored-by: Addison Phillips <addisonI18N@gmail.com> * Not using "localizable elements" Co-authored-by: Addison Phillips <addisonI18N@gmail.com> * Keep syntax.md in sync with message.abnf * Added note about surrogates to quoted literals * Moved the note about surrogates from Security Considerations to The Message * Update spec/syntax.md * Update spec/syntax.md * Italicize in a couple of places * Implemeted more (all?) feedback from review --------- Co-authored-by: Addison Phillips <addisonI18N@gmail.com> --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> Co-authored-by: Elango Cheran <elango@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Mark Davis <mark@unicode.org> Co-authored-by: Danny Gleckler <daniel.gleckler@d2l.com> Co-authored-by: Steven R. Loomis <srl295@gmail.com> Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> Co-authored-by: Eemeli Aro <eemeli@gmail.com> Co-authored-by: Mihai Nita <nmihai_2000@yahoo.com> * Add serialization proposal * Revert "Add serialization proposal" This reverts commit 17af553. * Revert "Update from main (#914)" This reverts commit da9377b. * Add serialization proposal --------- Co-authored-by: Eemeli Aro <eemeli@mozilla.com> Co-authored-by: Elango Cheran <elango@unicode.org> Co-authored-by: Tim Chevalier <tjc@igalia.com> Co-authored-by: Mark Davis <mark@unicode.org> Co-authored-by: Danny Gleckler <daniel.gleckler@d2l.com> Co-authored-by: Steven R. Loomis <srl295@gmail.com> Co-authored-by: Stanisław Małolepszy <sta@malolepszy.org> Co-authored-by: Eemeli Aro <eemeli@gmail.com> Co-authored-by: Mihai Nita <nmihai_2000@yahoo.com>
A continuation for #798 and #814, defining the composition behaviour for numerical values.