I am building a TypeScript interface generator from CDDL (https://github.com/jrandolf/cddlconv) and ran into an issue involving groupnames and typenames.
Problem
Consider the following schema:
apple = ( int );
apple is by definition a type, however the parser believes this is a group. This follows from the parser thinking that the int is a groupname rather than a typename which can only be known if
the parser understands primitive types or
the parser has pre-parsed for group names.
Solutions
Pre-parsing group names
This involves storing a set in the parser that keeps track of declared group names in group rules. Schemas will either be order-dependent or order-independent, depending on the implementation.
Pros (order-dependent)
Simple to implement.
Cons
Order-dependent schemas.
Pros (order-independent)
Order-independent schemas.
Cons
Requires parsing several times until the group name set stabilizes.
Slow.
Registered types (recommended)
This is the complement of the first solution. Rather than storing group names, we store a set of type names that will delineate groupname and typename. It's sufficient to store the initial primitive type names (e.g. int) since the parser can distinguish higher level types based on the grammar. Taking the above example, int would be stored as a typename, implying apple is also a type.
Pros
Simple to implement.
In practice, schemas remain semantic [1] even if they are order-independent in comparison to the first solution.
Cons
Requires order-dependent schemas (but in practice, may not matter; see above pros).
Requires users to register unknown types beforehand [2]
[1] E.g. SomeComplexType may be a group or type depending on when its constituents get declared, but the validation rules will likely remain the same.
[2] It can also be a pro as users can declare their own "primitives"
I am building a TypeScript interface generator from CDDL (https://github.com/jrandolf/cddlconv) and ran into an issue involving
groupname
s andtypename
s.Problem
Consider the following schema:
apple
is by definition a type, however the parser believes this is a group. This follows from theparser
thinking that theint
is agroupname
rather than atypename
which can only be known ifSolutions
Pre-parsing group names
This involves storing a set in the parser that keeps track of declared group names in group rules. Schemas will either be order-dependent or order-independent, depending on the implementation.
Pros (order-dependent)
Cons
Pros (order-independent)
Cons
Registered types (recommended)
This is the complement of the first solution. Rather than storing group names, we store a set of type names that will delineate
groupname
andtypename
. It's sufficient to store the initial primitive type names (e.g.int
) since the parser can distinguish higher level types based on the grammar. Taking the above example,int
would be stored as a typename, implyingapple
is also a type.Pros
Cons
[1] E.g.
SomeComplexType
may be a group or type depending on when its constituents get declared, but the validation rules will likely remain the same. [2] It can also be a pro as users can declare their own "primitives"