EBNF broken ? about opencypher HOT 10 CLOSED

Hello @walter-weinmann

This change is intentional. The reason for this is that Cypher as the query language of Neo4j the database has a number of features that we wouldn't like to standardise in openCypher, due to our goal of standardising a more general graph query language. In doing so, we need to remove these features altogether. In your above snippet, EXPLAIN, PROFILE, QueryOptions, etc are examples of Neo4j-specific features, which don't make sense in our view of what the language is supposed to handle.

We do realise that this is inconvenient for tool authors that want to support Cypher as it is used by Neo4j. To accommodate for this use case, you can include the legacy parsing rules in the generated EBNF by supplying a configuration flag to the generating tool. See here for more on that.

All the best
Mats

from opencypher.

Hi Mats

I'm only interested in the EBNF file. I'd like to extent my parser to
support both versions of the grammar. Therefore it would be a great help if
you could offer on the README.adoc the optional generation of legacy and
non-legacy output. Otherwise it would mean a a big effort for me to
maintain the whole development environment locally.

Thanks and regards

Walter

On 7 July 2016 at 11:36, Mats Rydberg [email protected] wrote:

Hello @walter-weinmann https://github.com/walter-weinmann

This change is intentional. The reason for this is that Cypher as the
query language of Neo4j the database has a number of features that we
wouldn't like to standardise in openCypher, due to our goal of
standardising a more general graph query language. In doing so, we need to
remove these features altogether. In your above snippet, EXPLAIN, PROFILE,
QueryOptions, etc are examples of Neo4j-specific features, which don't
make sense in our view of what the language is supposed to handle.

We do realise that this is inconvenient for tool authors that want to
support Cypher as it is used by Neo4j. To accommodate for this use case,
you can include the legacy parsing rules in the generated EBNF by supplying
a configuration flag to the generating tool. See here
https://github.com/opencypher/openCypher/tree/master/grammar#legacy-grammar
for more on that.

All the best
Mats

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#106 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB3ZNX2-HK6Aatwj48V9jrX0rwUe8at9ks5qTMifgaJpZM4JCGLU
.

Walter Weinmann

Obertorplatz 4
CH-4130 Rheinfelden
Tel +41 (0)61 841 06 10

Schulstrasse 1
CH-6037 Root
Tel +41 (0)41 530 39 70

from opencypher.

@walter-weinmann Sounds good. In the readme there are already instructions for how to generate both versions. By default, you're getting the standardised version. If you're supplying the legacy flag, you'll get the legacy version.

For the ISO EBNF file, that'd be (from the root of the repository, and given the creation of the grammar/generated directory):

./tools/grammar/src/main/shell/launch.sh ISO14977 --INCLUDE_LEGACY=true cypher.xml > grammar/generated/cypher.ebnf

Isn't that exactly what you were after?

from opencypher.

Not quite - I'd like to generate the EBNF variations directly from Github -
so I had always the current state of the grammars easily available. In my
understanding, what you suggest requires some local installation on my side.

On 7 July 2016 at 15:38, Mats Rydberg [email protected] wrote:

@walter-weinmann https://github.com/walter-weinmann Sounds good. In the
readme there are already instructions for how to generate both versions. By
default, you're getting the standardised version. If you're supplying the
legacy flag, you'll get the legacy version.

For the ISO EBNF file, that'd be (from the root of the repository, and
given the creation of the grammar/generated directory):

./tools/grammar/src/main/shell/launch.sh ISO14977 --INCLUDE_LEGACY=true cypher.xml > grammar/generated/cypher.ebnf

Isn't that exactly what you were after?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#106 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB3ZNeRLx6YviuLtdMJWp1z4ibkE9xqAks5qTQFlgaJpZM4JCGLU
.

Walter Weinmann

Obertorplatz 4
CH-4130 Rheinfelden
Tel +41 (0)61 841 06 10

Schulstrasse 1
CH-6037 Root
Tel +41 (0)41 530 39 70

from opencypher.

But the EBNF file is not stored on GitHub. Are you referring to this file from AWS?

from opencypher.

Yes - that's a very convenient way to get the relevant data.

On 7 July 2016 at 15:57, Mats Rydberg [email protected] wrote:

But the EBNF file is not stored on GitHub. Are you referring to this file
https://s3.amazonaws.com/artifacts.opencypher.org/cypher.ebnf from AWS?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#106 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB3ZNUBQNaNq0-CdhVmPci0haNbKtyP7ks5qTQWwgaJpZM4JCGLU
.

Walter Weinmann

Obertorplatz 4
CH-4130 Rheinfelden
Tel +41 (0)61 841 06 10

Schulstrasse 1
CH-6037 Root
Tel +41 (0)41 530 39 70

from opencypher.

I see. I'll make sure that we generate the legacy file and add it to the same location.

from opencypher.

That's really great.

Last question: will legacy always be a superset of openCypher or will they
develop in future into different directions?

Thanks and regards

Walter

On 7 July 2016 at 16:31, Mats Rydberg [email protected] wrote:

I see. I'll make sure that we generate the legacy file and add it to the
same location.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#106 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB3ZNREsRE6FoPVmzcjyk0eXItkt9Dqwks5qTQ3bgaJpZM4JCGLU
.

Walter Weinmann

Obertorplatz 4
CH-4130 Rheinfelden
Tel +41 (0)61 841 06 10

Schulstrasse 1
CH-6037 Root
Tel +41 (0)41 530 39 70

from opencypher.

Legacy is not meant to develop in any direction, but will remain in its current form until we are confident enough that it is completely useless and remove it. Currently it is useful because the only Cypher implementation known (Neo4j) supports it. The next major version of Neo4j is likely to remove support for several of these features.

That said, we decided to make the grammar handle this so that the answer to your question is yes. There is a set of grammar rules that are marked as legacy, and the legacy grammars will use the latest version of the openCypher grammar and simply add the legacy set to it.

from opencypher.

@walter-weinmann You'll find the legacy grammars in a subdirectory legacy in the same AWS bucket. For the ISO EBNF, use this link: https://s3.amazonaws.com/artifacts.opencypher.org/legacy/cypher.ebnf.

I'm closing this as resolved, please correct me if you have any remaining questions.

from opencypher.