Example: <atom ... name="Si"/> (default Si name) Allowed values: 20 alphanumeric characters maximum (defined in GAMGI_ENGINE_TOKEN) (optional)
Identifier attributes must be unique for each import or export operation, as they are used by GAMGI to relate elements that may not even be in the same file. Although GAMGI uses numbers as identifier attributes when exporting files, these are not related in any way with the object numbers used internally in GAMGI to identify the objects. Identifier attributes are required only when the respective elements must be referenced somewhere else, most notably in bonded atoms that must be referenced by the bonds.
Example: <atom ... id="si1"/> (no default) Allowed values: 20 alphanumeric characters maximum (defined in GAMGI_ENGINE_TOKEN) (optional, required if bonded)
Example: <atom ... parent="layer1"/> (no default) Allowed values: 20 alphanumeric characters maximum (defined in GAMGI_ENGINE_TOKEN) (optional)Objects can reference parents that are only defined later, perhaps in another file, or perhaps in another file included by another file, without any limit to the level of depth of nested files. For example, a bond in a file can reference atoms that are defined in a HTTP file, fetched from somewhere in the planet. Configuration data elements have fixed parents, so identifiers don't apply to them.
We note that an object can only reference other objects that are inside the block defined by its own parent. This important restriction was introduced to disable all kinds of weird referencing possibilities that are left open with global identifiers, where everything can point to everything, potentially destroying the strict hierarchy that XML files should have, and making it difficult for GAMGI and users alike to check and understand the objects true hierarchy.
Moreover, this mechanism can never be used to validate an object that has an impossible object enclosing it by pointing it to a correct parent. The XML hierarchical position of an object in a file must always be possible, independently of its parameters.
This automatically prevents, for example, atoms belonging to different layers from being bonded together, as bonds in one layer cannot see atoms that are in the other layer. To see both atoms, bonds would have to belong to the common window, which is forbiden, because windows cannot own bonds, only layers.
<gml> <bond parent1="1" parent2="2"/> bond can reference parents that are defined later <group> <atom id="1"/> atom is inside the bond scope (the current layer block) </group> <atom id="2"/> </gml>
<gml> <atom id="1"/> <atom id="2"/> <group> <bond parent1="1" parent2="2"/> atoms are outside the bond scope (the group block) </group> </gml>