Tobias Lindaaker

I came across this difference when looking at why the `whitespace` production rules spelled out all whitespace characters individually instead of just referencing the unicode [`[:White_Space:]`](https://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AWhite_Space%3A%5D) specification. So I investigated...

If we agree to use the unicode [`[:White_Space:]`](https://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AWhite_Space%3A%5D) specification, we could define whitespace as: ```xml ```

Looking at commit history, it appears as if at some point Java's `Character.isWhitespace(int)` treated [`\u180E` (MONGOLIAN VOWEL SEPARATOR)](https://unicode.org/cldr/utility/character.jsp?a=180E) as a whitespace. At least that is what the code comments say....

The `FILE SEPARATOR`, `GROUP SEPARATOR`, `RECORD SEPARATOR`, and `UNIT SEPARATOR` have been explicitly treated as whitespace by Java since forever, and thus by the Neo4j Cypher parser. They are likely...

Related to [CIR-2017-178](https://github.com/opencypher/openCypher/issues/178).

This has been requested as a feature for Neo4j in neo4j/neo4j#5092, but since it requires additions to the Cypher language, it really should be handled through the openCypher process.

Aims to solve #174

If we end up with the syntax proposed in [CIP2017-02-06](https://github.com/opencypher/openCypher/pull/187) for Regular Path Queries, we might be able to extend this syntax to mean approximate matching as described here by...

I really like this idea.

I actually think it is at least worth considering whether `UNWIND` and `OPTIONAL UNWIND` should both treat `null` and `[]` the same. I.e. what has been proposed in the [UNWIND...