in Set-Inclusion and Parent-Child structures.

There are two graph-like structures in the iMesh interface and data model; the set-inclusion structure and the parent-child link structure. Whether these structures support cycles is relevant to implementors.

Over the evolution of the iMesh data model and API, both of these structures have been viewed more or less like a tree and so cycles seem incompatible with that notion.

Allowing a cycle in the set inclusion structure implies all entity sets in the cycle are all equal to each other. That is the only rational, model-level view that would allow them all to be (improper) subsets of each other. On the other hand if the iMesh specification excludes cycles from the set inclusion structure, the time complexity (performance) as a function of the number of entity sets may be prohibitive for implementations to detect and prevent them.

Allowing a cycle in the parent-child link structure seems likewise hard to justify. However, when the parent-child structure is viewed more like a general graph (a view that the current API itself supports even if the function names themselves do not suggest that) than specifically a tree, the admission of cycles there is potentially more natural and useful.

Implementations are required to support cycles in the Parent-Child structure. Implementations are neither required to support nor required to explicitly prevent cycles in the Set-Inclusion structure. Portable applications should NOT rely on implementations support for cycles in the set-inclusion structure.