unicode-org
diff --git a/‎CONTRIBUTING.md
Lines changed: 8 additions & 1 deletion b/‎CONTRIBUTING.md
Lines changed: 8 additions & 1 deletion
diff --git a/‎README.md
Lines changed: 9 additions & 38 deletions b/‎README.md
Lines changed: 9 additions & 38 deletions
diff --git a/‎exploration/bidi-usability.md
Lines changed: 22 additions & 49 deletions b/‎exploration/bidi-usability.md
Lines changed: 22 additions & 49 deletions
diff --git a/‎exploration/expression-attributes.md
Lines changed: 1 addition & 3 deletions b/‎exploration/expression-attributes.md
Lines changed: 1 addition & 3 deletions
@@ -1,6 +1,13 @@
 # Contributing to this project
 
-To join this Working Group, please read the information in the [README.md](./README.md) as well as the Contributor License Agreement information just below:
+## Joining the Working Group
+
+We are looking for participation from software developers, localization engineers and others with experience
+in Internationalization (I18N) and Localization (L10N). If you wish to contribute to this work, please review
+the information on the Contributor License Agreement below. In addition, you should:
+
+1. Apply to join our [mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+2. Watch this repository (use the "Watch" button in the upper right corner)
 
 <!-- boilerplate follows - do not edit -->
 
 
@@ -76,8 +76,7 @@ Functions can optionally take _options_:
 Messages can use a _selector_ to choose between different _variants_,
 which correspond to the grammatical (or other) requirements of the language:
 
-    .input {$count :integer}
-    .match $count
+    .match {$count :integer}
     0   {{You have no notifications.}}
     one {{You have {$count} notification.}}
     *   {{You have {$count} notifications.}}
@@ -106,23 +105,6 @@ The `main` branch of this repository contains changes implemented since the tech
 Implementers should be aware of the following normative changes during the tech preview period.
 See the [commit history](https://github.com/unicode-org/message-format-wg/commits) 
 after 2024-04-13 for a list of all commits (including non-normative changes).
-- [#885](https://github.com/unicode-org/message-format-wg/issues/885) Address equality of `name` and `literal` values, including requiring keys to use NFC
-- [#884](https://github.com/unicode-org/message-format-wg/issues/884) Add support for bidirectional isolates and strong marks in syntax and address UAX31/UTS55 requirements
-- [#883](https://github.com/unicode-org/message-format-wg/issues/883) Remove forward-compatibility promise and all reserved/private syntax.
-- [#882](https://github.com/unicode-org/message-format-wg/issues/882) Specify `bad-option` error for bad digit size options in `:number` and `:integer` functions
-- [#878](https://github.com/unicode-org/message-format-wg/issues/878) Clarify "rule" selection in `:number` and `:integer` functions
-- [#877](https://github.com/unicode-org/message-format-wg/issues/877) Match on variables instead of expressions. 
-- [#854](https://github.com/unicode-org/message-format-wg/issues/854) Allow whitespace at complex message start
-- [#853](https://github.com/unicode-org/message-format-wg/issues/853) Add a "duplicate-variant" error
-- [#845](https://github.com/unicode-org/message-format-wg/issues/845) Define "attributes" feature
-- [#834](https://github.com/unicode-org/message-format-wg/issues/834) Modify the stability policy (not currently in effect due to Tech Preview)
-- [#816](https://github.com/unicode-org/message-format-wg/issues/816) Refine error handling
-- [#815](https://github.com/unicode-org/message-format-wg/issues/815) Removed machine-readable function registry as a deliverable
-- [#813](https://github.com/unicode-org/message-format-wg/issues/813) Change default of `:date` and `:datetime` date formatting from `short` to `medium`
-- [#812](https://github.com/unicode-org/message-format-wg/issues/812) Allow trailing whitespace for complex messages
-- [#793](https://github.com/unicode-org/message-format-wg/issues/793) Recommend the use of escapes only when necessary
-- [#775](https://github.com/unicode-org/message-format-wg/issues/775) Add formal definitions for variable, external variable, and local variable
-- [#774](https://github.com/unicode-org/message-format-wg/issues/774) Refactor errors, adding Message Function Errors
 - [#771](https://github.com/unicode-org/message-format-wg/issues/771) Remove inappropriate normative statement from errors.md
 - [#767](https://github.com/unicode-org/message-format-wg/issues/767) Add a test schema and
   [#778](https://github.com/unicode-org/message-format-wg/issues/778) validate tests against it
@@ -131,9 +113,7 @@ after 2024-04-13 for a list of all commits (including non-normative changes).
 - [#769](https://github.com/unicode-org/message-format-wg/issues/769) Add `:test:function`,
   `:test:select` and `:test:format` functions for implementation testing
 - [#743](https://github.com/unicode-org/message-format-wg/issues/743) Collapse all escape sequence rules into one (affects the ABNF)
-
-In addition to the above, the test suite is significantly modified and updated.
-
+- _more to be added as they are merged_
 
 ## Implementations
 
@@ -157,27 +137,18 @@ We invite feedback about the current syntax draft, as well as the real-life use-
 - General questions and thoughts → [post a discussion thread](https://github.com/unicode-org/message-format-wg/discussions).
 - Actionable feedback (bugs, feature requests) → [file a new issue](https://github.com/unicode-org/message-format-wg/issues).
 
-## Participation / Joining the Working Group
-
-We are looking for participation from software developers, localization engineers and others with experience
-in Internationalization (I18N) and Localization (L10N). 
-If you wish to contribute to this work, please review the information about the Contributor License Agreement below. 
+## Participation
 
-To follow this work:
-1. Apply to join our [mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
-2. Watch this repository (use the "Watch" button in the upper right corner)
+To join in:
 
-To contribute to this work, in addition to the above:
-1. Each individual MUST have a copy of the CLA on file. See below.
-2. Individuals who are employees of Unicode Member organizations SHOULD contact their member representative.
-   Individuals who are not employees of Unicode Member organizations MUST contact the chair to request Invited Expert status.
-   Employees of Unicode Member organizations MAY also apply for Invited Expert status,
-   subject to approval from their member representative.
+1. Review [CONTRIBUTING.md](./CONTRIBUTING.md)
+2. Apply to join our 
10000
[mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+3. Watch this repository (use the "Watch" button in the upper right corner)
 
 ### Copyright & Licenses
 
 Copyright © 2019-2024 Unicode, Inc. Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in the United States and other countries.
 
-A CLA is required to contribute to this project - please refer to the [CONTRIBUTING.md](./CONTRIBUTING.md) file (or start a Pull Request) for more information.
+The project is released under [LICENSE](./LICENSE).
 
-The contents of this repository are governed by the Unicode [Terms of Use](https://www.unicode.org/copyright.html) and are released under [LICENSE](./LICENSE).
+A CLA is required to contribute to this project - please refer to the [CONTRIBUTING.md](./CONTRIBUTING.md) file (or start a Pull Request) for more information.
@@ -273,39 +273,6 @@ Not allowing these to mix could produce annoying parse errors.
 
 _Describe the proposed solution. Consider syntax, formatting, errors, registry, tooling, interchange._
 
-I propose adopting a hybrid approach in which we permit "super-loose isolation".
-This allows user to include isolates and strongly directional characters into the whitespace
-portions of the syntax in order to make messages appear correctly.
-
-The second part of the hybrid approach would be to recommend ("SHOULD") the "strict isolation"
-design for serializers.
-(Note that "strict" and "super-loose" use non-identical productions with the name `bidi`.
-These serve different purposes and are consistent with strict being narrower with super-loose.)
-This syntax is a subset of the super-loose syntax and can be applied selectively to messages that
-have RTL sequences or which have problematic display.
-
-
-## Alternatives Considered
-
-_What other solutions are available?_
-_How do they compare against the requirements?_
-_What other properties they have?_
-
-### Nothing
-We could do nothing.
-
-A likely outcome of doing nothing is that RTL users would insert bidi controls into
-_messages_ in an attempt to make the _pattern_ and/or _placeholders_ display correctly.
-These controls would become part of the output of the _message_,
-showing up inappropriately at runtime.
-Because these characters are invisible, users might be very frustrated trying to manage
-the results or debug what is wrong with their messages.
-
-By contrast, if users insert too many or the wrong controls using the recommended design,
-the _message_ would still be functional and would emit no undesired characters.
-
-### LTR Messages with isolating sequences
-
 The syntax of a _message_ assumes a left-to-right base direction
 both for the complete text of the _message_ as well as for each line (paragraph)
 contained therein. 
@@ -416,7 +383,7 @@ ns-separator   = [bidi] ":"
 bidi           = [ %x200E-200F / %x061C ]
 ```
 
-**Open Issues**
+### Open Issues with Proposed Design
 
 The ABNF changes found above put isolates and strongly directional marks into specific locations,
 such as directly next to `{`/`}`/`{{`/`}}` markers
@@ -426,24 +393,32 @@ A more permissive design would add the isolates and strongly directional marks t
 whitespace in the syntax and depend on users/editors to appropriately pair or position the marks
 to get optimal display.
 
+## Alternatives Considered
+
+_What other solutions are available?_
+_How do they compare against the requirements?_
+_What other properties they have?_
+
+### Nothing
+We could do nothing.
+
+A likely outcome of doing nothing is that RTL users would insert bidi controls into
+_messages_ in an attempt to make the _pattern_ and/or _placeholders_ display correctly.
+These controls would become part of the output of the _message_,
+showing up inappropriately at runtime.
+Because these characters are invisible, users might be very frustrated trying to manage
+the results or debug what is wrong with their messages.
+
+By contrast, if users insert too many or the wrong controls using the recommended design,
+the _message_ would still be functional and would emit no undesired characters.
 
 ### Super-loose isolation
 
 Add isolates and strongly directional marks to required and optional whitespace in the syntax.
 This would permit users to get the effects described by the above design,
 as long as they use isolates/marks in a "responsible" way.
 
-The exception to this is the namespace separator, used in `identifier`.
-This requires the ability to insert isolates or strongly directional marks
-between the namespace and name portions, where whitespace is not permitted.
-This is the only location in the syntax where such characters might be needed
-but whitespace is not at least optional.
-This could be defined as:
-```abnf
-ns-separator   = [bidi] ":" [bidi]
-```
-
-Here are the other ABNF changes:
+(Omitting other changes found in #673)
 
 ```abnf
 ; strongly directional marks and bidi isolates
@@ -472,7 +447,7 @@ s = ( SP / HTAB / CR / LF / %x3000 )
 ### Strict isolation all the time
 
 Apply bidi isolates in a strict way.
-In this design:
+The main differences to the proposed solution is:
 1. The open/close isolate characters are syntactically required to be paired.
    This introduces parse errors for unpaired invisible characters,
    which could lead to bad user experiences.
@@ -492,7 +467,7 @@ markup         = "{" [s] "#" identifier [bidi] *(s option) *(s attribute) [s] ["
                / "{" [s] "/" identifier [bidi] *(s option) *(s attribute) [s] "}"  ; close
                / "{" LRI [s] "/" identifier [bidi] *(s option) *(s attribute) [s] close-isolate "}"  ; close
 identifier     = [(namespace ns-separator)] name
-ns-separator   = [bidi] ":" [bidi]
+ns-separator   = [bidi] ":"
 bidi           = [ %x200E-200F / %x061C ]
 ```
 
@@ -635,8 +610,6 @@ adherence to the stricter grammar.
   syntax errors
 - Provides a foundation for tools to claim strict conformance and message normalization
   as well as guidance to implementers to make them want to adopt it
-- Messages are valid while being edited (such as when the open or close isolate has been
-  inserted but the corresponding opposite isolate hasn't been entered yet)
 
 **Cons**
 - Requires additional effort to maintain the grammar
 
@@ -1,6 +1,6 @@
 # Expression Attributes
 
-Status: **Accepted**
+Status: **Proposed**
 
 <details>
 	<summary>Metadata</summary>
@@ -15,8 +15,6 @@ Status: **Accepted**
 		<dd><a href="https://github.com/unicode-org/message-format-wg/pull/772">#772</a></dd>
 		<dd><a href="https://github.com/unicode-org/message-format-wg/pull/780">#780</a></dd>
 		<dd><a href="https://github.com/unicode-org/message-format-wg/pull/792">#792</a></dd>
-		<dd><a href="https://github.com/unicode-org/message-format-wg/pull/845">#845</a></dd>
-		<dd><a href="https://github.com/unicode-org/message-format-wg/pull/846">#846</a></dd>
 	</dl>
 </details>