Consistently use the "JEP-#" pattern (#145)

* Document the JEP-# pattern

* Update "JEP N" to "JEP-N" in recent JEPs

* Update "JEP N" to "JEP-N" in ported JEPs

* Merged #146.

Co-authored-by: Maxime Labelle <[email protected]>

README.md

@@ -32,9 +32,9 @@ proposal should be considered despite similar proposals not being accepted.
 Writing a JEP can be a lot of work, so it can help to get initial guidance before getting too far. You can chat on the JMESPath gitter channel
 (https://gitter.im/jmespath/chat) to get an initial pulse of a new feature.
 
-Then open a [discussion](https://github.com/jmespath-community/jmespath.spec/discussions) to discuss the feature, its merit, and any possible
-alternatives. Once the discussion has reached a mature level of feedback it will be assigned a JEP#. At this point it is safe to begin composing a
-JEP, along with all the required changes and documentation.
+Then open a [discussion](https://github.com/jmespath-community/jmespath.spec/discussions) to discuss the feature, its merit, and any possible alternatives.
+Once the discussion has reached a mature level of feedback, it will be assigned a JEP number _N_.
+At that point it is safe to begin composing JEP-_N_ along with all the required changes and documentation.
 
 ### Tenets of JMESPath
 

jep-003-functions.md

@@ -577,7 +577,7 @@ JMESPath expression.
 
 
 * This JEP originally proposed the literal syntax. The literal portion of this
-JEP was removed and added instead to JEP 7.
+JEP was removed and added instead to JEP-7.
 
 
 * This JEP originally specified that types matches should return null.  This

jep-007-filter-expressions.md

@@ -12,7 +12,7 @@
 This JEP proposes grammar modifications to JMESPath to allow for filter
 expressions.  A filtered expression allows list elements to be selected
 based on matching expressions.  A literal expression
-is also introduced (from JEP 3) so that it is possible to match elements
+is also introduced (from JEP-3) so that it is possible to match elements
 against literal values.
 
 ## Motivation

jep-009-improved-filters.md

@@ -9,7 +9,7 @@
 
 ## Abstract
 
-JEP 7 introduced filter expressions, which is a mechanism to allow
+JEP-7 introduced filter expressions, which is a mechanism to allow
 list elements to be selected based on matching an expression against
 each list element.  While this concept is useful, the actual comparator
 expressions were not sufficiently capable to accomodate a number of common
@@ -21,7 +21,7 @@ of queries.
 
 ## Motivation
 
-JEP 7 introduced filter queries, that essentially look like this:
+JEP-7 introduced filter queries, that essentially look like this:
 
 ```
 foo[?lhs omparator rhs]
@@ -34,7 +34,7 @@ are both an `expression`, and comparator is one of
 This added a useful feature to JMESPath: the ability to filter
 a list based on evaluating an expression against each element in a list.
 
-In the time since JEP 7 has been part of JMESPath, a number of cases have been
+In the time since JEP-7 has been part of JMESPath, a number of cases have been
 pointed out in which filter expressions cannot solve.  Below are examples of
 each type of missing features.
 
@@ -366,8 +366,8 @@ expressions, but is now allowed as a general `expression`.
 which again is just a general `expression`.
 
 There are several reasons the previous grammar rules were minimally scoped.
-One of the main reasons, as stated in JEP 7 which introduced filter
+One of the main reasons, as stated in JEP-7 which introduced filter
 expressions, was to keep the spec “purposefully minimal.”  In fact the end
-of JEP 7 states that there “are several extensions that can be added in
+of JEP-7 states that there “are several extensions that can be added in
 future.” This is in fact exactly what this JEP proposes, the recommendations
-from JEP 7.
+from JEP-7.

jep-010-slice-projections.md

@@ -15,7 +15,7 @@ flattening, and filtering projections.
 
 ## Motivation
 
-JEP 5 introduced slice expressions.  This added python slice semantics
+JEP-5 introduced slice expressions.  This added python slice semantics
 to JSON.  Slicing does not produce a projection so expressions such as
 the following will always return `null`:  `myarray[:10].foo.bar`.
 

jep-012-raw-string-literals.md

@@ -277,9 +277,9 @@ implementations.
 In order to support this type of variance in JMESPath implementations, all of
 the JSON literal compliance test cases that involve elided quotes MUST be
 removed, and test cases regarding failing on invalid unquoted JSON values MUST
-not be allowed in the compliance test unless placed in a JEP 12 specific
+not be allowed in the compliance test unless placed in a JEP-12 specific
 test suite, allowing implementations that support elided quotes in JSON
-literals to filter out the JEP 12 specific test cases.
+literals to filter out the JEP-12 specific test cases.
 
 ## Alternative approaches
 

jep-015-string-slices.md

@@ -10,7 +10,7 @@
 
 ## Abstract
 
-The original [JEP 5](https://github.com/jmespath-community/jmespath.spec/blob/main/jep-005-array-slices.md) introduced `slice-expression` in the grammar to slice specific portions of an array. While the syntax was specifically designed to operate on arrays, the syntactic grammar allows it after any expression.
+The original [JEP-5](https://github.com/jmespath-community/jmespath.spec/blob/main/jep-005-array-slices.md) introduced `slice-expression` in the grammar to slice specific portions of an array. While the syntax was specifically designed to operate on arrays, the syntactic grammar allows it after any expression.
 
 This JEP introduces changes to allow `slice-expression` to operate on string types and act like a more powerful `substring()` function.