🠕

3.1 A Metasyntax for Structure Organization

The structures, with their payloads and substructures, are represented using a custom metasyntax. The intent of this metasyntax is to resemble the line encoding of allowable structures. In the metasyntax:

  • Options are placed between brackets [ and ] and have choices separated by pipes |.

  • Named sets of rules are indicated with a name followed by :=.

  • Level markers are used to indicate substructure relationships.

    • 0 means “must be a record”.
    • n means “level inherited from rule instantiation”.
    • +1, +2, etc., indicate nesting within nearest preceding structure with lesser level.
  • Four cardinality markers are used: {0:1}, {1:1}, {0:M}, and {1:M}.

    • {0: means “optional” – the structure may be omitted
    • {1: means “required” – at least 1 must appear
    • :M} means “any number” – 1 or more structures may appear. Unless otherwise specified, the first is the most-preferred value. If an application needs to display just 1 of several NAMEs, BIRTs, etc, they should show the first such structure unless more specific selection criteria are available.
    • :1} means “singular” – at most 1 may appear; a second must not be present.

    Systems interested in violating the cardinality rules should instead create extension structures with different cardinality.

  • Rule instantiation is indicated by the rule name in double angle-brackets (such as <<rule name>>) and a cardinality marker.

    The cardinality markers of rule instantiations and their referenced line templates are combined such that the resulting cardinality is required only if both combined cardinalities are required and singular only if both combined cardinalities are singular.

    The definition of the FAM record has the line

      +1 <<CREATION_DATE>>                     {0:1}

    and the CREATION_DATE rule begins

    n CREA                                     {1:1}  g7:CREA
    Thus, a FAM record has an optional singular CREA substructure (such as cardinality {0:1}).
  • Line templates have several parts:

    • An optional cross-reference template @XREF:tag@, meaning this structure may be pointed to by other structures.

      Structures that are not pointed to by other structures need not have a cross-reference identifier even if their line template has a cross-reference template.

    • The standard tag for this structure.

    • An optional payload descriptor; if present this is 1 of the following:

      • @<XREF:tag>@ means a pointer to a structure with this cross-reference template; @VOID@ is also permitted.
      • <data type> means a non-pointer payload, as described in Data types. If the data type allows the empty string, the payload may be omitted.
      • [text|<NULL>] means the payload is optional but if present must be the given text.

      If there is a payload descriptor, a payload that matches the payload is required of the described structure unless the descriptor says the payload is optional.

      If there is no payload descriptor, the described structure must not have a payload.

    • A cardinality marker.

    • The URI of this structure type.

      Pseudo-structures do not have a URI.

  • Within the metasyntax, the order in which substructures are presented within a structure and the order in which choices are presented within an option set are not significant unless otherwise specified in the text next to the metasyntax block.

The context of a structure’s superstructure may be necessary in addition to the structure’s standard tag to fully determine its structure type. To refer to a structure in the context of its superstructure, tags are written with intervening periods. For example, GEDC.VERS refers to a structure with tag VERS and a superstructure with tag GEDC.