Trying to understand the OpenCypher basic grammar

[Patrick Wendo]

Newbie to the OpenCypher and GQL space, could someone please explain what WS and SP are within the !DOCTYPE definitions?

[Hannes Voigt]

These are macros that are frequently used in the rest of the grammar for whitespace definitions. The underlying macro mechanism is an XML thing, cf. https://www.w3schools.com/xml/xml_dtd_entities.asp

-Hannes

[Patrick Wendo]

ohhh, that makes a lot more sense.

I am working on a general BNF format translation from the XML, and I am wondering if there was a specific reason this grammar was written in XML?

[Patrick Wendo]

Hi Guys, I have tried to translate the basic-grammar into BNF

I am stuck on a couple things I was hoping you guys could assist me with. For instance I am yet to figure out the representation for the file-separator, group separator, record separator, unit separator and eoi. Similarly I am unsure on how to represent the ID-start and ID-continue in BNF

You can checkout the gist to the Open Cypher Basic Grammar in BNF ( https://gist.github.com/W3NDO/811d3fa6f28a39b1a7621f0c7d84273d#file-open-cypher-basic-grammar-bnf )

[Hannes Voigt]

Hi Patrick,

the grammar is in XML so that is machine readable, e.g. to generate railroad diagrams or a parser from it, cf. grammar tools. These tools can also generate EBNF and even the BNF format used in ISO SQL and GQL standard documents. This is how released EBNF grammar is generated. To see how to run these things have a look at upload-release.sh script.

To you over questions:

      <!-- ASCII whitespace characters -->
      <character set="SPACE"/> <!-- SPACE -->
      <character set="TAB"/> <!-- (Horisontal) Tab -->
      <character set="LF"/> <!-- Line Feed -->
      <character set="VT"/> <!-- Vertical Tab -->
      <character set="FF"/> <!-- Form Feed -->
      <character set="CR"/> <!-- Carriage Return -->
      <character set="FS"/> <!-- File Separator -->
      <character set="GS"/> <!-- Group Separator -->
      <character set="RS"/> <!-- Record Separator -->
      <character set="US"/> <!-- Unit Separator -->

refer to, as the comment says, ASCII characters (which also have a unicode representation), cf.

- https://www.ascii-code.com/characters/white-space-characters

- https://www.ascii-code.com/characters/control-characters

- https://www.ascii-code.com/character/%E2%90%9F

The railroad diagrams have links to unicode spec page that make clear which characters are meant.

ID-start and ID-continue refer to unicode properties, cf.

- https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?abb=on&esc=on&a=%5B%3AID_Start%3A%5D%5D

- http://unicode.org/reports/tr31/

Best

-Hannes

[Patrick Wendo]

Hi Hannes,

Thank you so much for your explanation.

I'm now realizing there is a lot I need to get familiarized with

Best,

- Wendo

[Duane Nickull]

Patrick:

If you are just starting out with XML, the best place to start with is the XML infoset recommendation.

https://www.w3.org/TR/2004/REC-xml-infoset-20040204/

This defines the 11 or some basic types of data constructs that are present in any XML document.  This is used as the base abstract model for XML itself. One of the most important items to pay attention to is the character encoding scheme.  There are many different encodings including ISO 8859 and UTF.  As Hannes wrote, this is perhaps the most germaine part of the relationship.

I would also recommend understanding the parsing/processing models which are not part of the Infoset specification. Although my name is not on that specification as a contributor, I did a lot of work with XML, XSLT, XSL and other related specifications that dealt with this.

Furthermore, keep in mind that XML is merely the expression of a data model.  XML schema and DTD's can be used to constrain the model, but there are limitations to it.  XML schema , for example, has logic errors that may be expressed and will not throw a parsing error.  One example is the following:

<xsd:element name="myBadExample">
  <xsd:complexType>
    <xsd:choice>
      <xsd:element name="option1" type="xsd:string" minOccurs="1" />
      <xsd:element name="option2" type="xsd:string" minOccurs="1" />

      <xsd:element name="option3" type="xsd:short" maxOccurs="2" minOccurs="2" />
     </xsd:choice>
   </xsd:complexType>
</xsd:element>

The choice element indicates that only one child element can be used yet the child elements all state that they must occur a minimum number of times greater than 1.  This breaks the model and not all parsers treat this the same.

Why am I mentioning this on a Cypher related list?  It is just to make you aware that not everything about the XML family of recommendations is 100% baked or perfect.  Some of this is worth considering when working with converting XML based models to other formats.

Best wishes,

Duane Nickull

--
You received this message because you are subscribed to the Google Groups "openCypher" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencypher+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencypher/02cf6aee-05c5-4744-a3a7-8984a0c2da23n%40googlegroups.com.

--

******************************
CTO Hired Gun - speaking only for myself

s. Bootstrap 5, jQuery, HTML5, CSS3+, PHP, Node.js, Neo4J & more

@duane...@hachyderm.io

NOTICE: This e-mail and any attachments may contain confidential information. If you are the intended recipient, please consider this a privileged communication, not to be forwarded without explicit approval from the sender.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. The originator reserves the right to monitor all e-mail communications through its networks for quality control purposes.