# openEHR grammar generalities

**URL:** <https://discourse.openehr.org/t/openehr-grammar-generalities/1875>\
**Category:** Specifications\
**Tags:** grammars\
**Created:** [20 September 2021 21:18 UTC](https://discourse.openehr.org/t/openehr-grammar-generalities/1875 "2021-09-20T21:18:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [20 September 2021 21:18 UTC](https://discourse.openehr.org/t/openehr-grammar-generalities/1875/1 "2021-09-20T21:18:39Z")

</div>

Following @pablo 's recent post on Terminology Ids, I was having a look at some really basic things, including definitions for Integer, which appear in versions as well as numbers and parts of Reals/floats etc.

We currently define it as follows:

```auto
INTEGER: DIGIT+ ;

```

But that allows zero-filled integers, which are at least weird, if not usually some sort of stringified 0-filled integer…

I had a look at Kotlin (just picking on a ‘modern’ language), and it has:

```auto
IntegerLiteral
    : DecDigitNoZero DecDigitOrSeparator* DecDigit
    | DecDigit // including '0'
    ;

```

i.e. no zero-filling. [Java is similar](https://github.com/antlr/grammars-v4/blob/master/java/java9/Java9Lexer.g4):

```auto
fragment
DecimalNumeral
	:	'0'
	|	NonZeroDigit (Digits? | Underscores Digits)
	;

```

Now when we create version ids, we don’t want zero-filling, at least I don’t think we do. I wonder if we ought to define INTEGER like this:

```auto
INTEGER: '0' | [1-9][0-9]*

```

Then Version id is something like this:

```auto
VERSION_ID : INTEGER '.' INTEGER '.' INTEGER VERSION_MOD? ;
fragment VERSION_MOD: ( '-rc' | '-alpha' ) ( '.' DIGIT+ )? ;

```

This allows zero-filling in the numeric part of the version modifier, on the assumption that this part isn’t necessarily understood as a proper number.

Related: should we allow zero-filled Real numbers? Kotlin says yes, [so does Java](https://github.com/antlr/grammars-v4/blob/master/java/java9/Java9Lexer.g4#L295).

Reals probably don’t matter that much, since they serve only one purpose, but Integers are both numbers and also pieces of many kinds of Ids, including version ids, OIDs, and so on.

I am tempted to follow kotlin and Java, and define INTEGER as a non-zero-filled numeric. Would this break anything?

We can also solve the problem another way, as I have done now, and just define a separate matcher fragment for non-zero-filled Integers:

```auto
fragment NUMBER : '0' | [1-9][0-9]* ;

```

Thoughts?