The idea of Hilang segments borrowed from Network and hierarchical databases that were popular long before the relational model became dominant, but recently resurrected for document store databases. From an application perspective a reference to a segment behaves the same as a set of values - the functional difference is how they are stored.

When HiLang segments are generated to code they inherit an owner reference to their parent at the start of the key, but since segments are generally always accessed via their parent, the domain application does not need to set the owner value (it is added automatically). Segments normally only have one parent since they are most useful for modelling hierarchies of Master/Detail but could be applied to any entity/segment/aspect for cases like cost attribution. The TOGAF is one example when {Principle, Constraint, Assumption, Requirement, Location, Gap, Work-Package} can be applied to any of the main entities within the schema model. Applying a Togaf.Has.Constraint { Id = 1234, Name = "KYC", Description = "Know Your Customer"} from Togaf.Business.Capability to Togaf.Service is add simple as my_payment_service.Constriant.Add (my_payment_capability.Constraint[0] without the implementation detail that Togaf.Business.CapabilityConstraint ( owner : Togaf.Business.Capability ...) is being copied to Togaf.ServiceConstraint ( owner : ServiceConstraint ..).

It's We're considering two examples where Segments or values could be used. In one case, we have the task/resource master/detail and in the other we have Order/Line master detail. Task has been modelled with segment, while order has been modeled with a a Lines : Set<OrderLine>

Task / Resource

The UML diagram shows the aggregation of TaskResource by Task. TaskResource can be added to a Task's TaskResource property, or directly to the Plan.PlanSpace.TaskResources set. Task does not hold a collection of TaskResource references as a value but derives it from the segment extension if required.

Because TaskResources is stored separately in Hiperspace, it cannot be deleted (without using a pruning process), so removal is achieved by updating the value with Deleted = true and a SubSpace horizon that hides deleted records.

As TaskResources is stored in and accessible from a SubSpace is can provide a Node/Edge views for viewing as a graph.

When saving the Task to XML or JSON text, the TaskResources are optional.

Order / Line

The UML diagram shows the containment of Orderline within Order. OrderLine can be added to or removed from an Order's Lines property, **but** not or directly in the ERP.ERPSpace`.

Because OrderLine is not stored separately in the SubSpace it cannot provide a Node/Edge views for viewing as a graph.

When saving the Order to XML or JSON text, the Lines are always included.

Considerations

Performance

The two examples were chosen because of similarities but scaling out master/detail relationships to thousands or millions of detail references results in very different performance. When you always need the full details containment by value is always going to be quicker, but when references are loaded with very low latency the case is significantly diminished. When most use-cases only need part of the document segments are considerably quicker and more efficient.

Integrity

While it is common for entities to be versioned, it is optional. If an entity is not versioned, segments allow details to be added without changing the inviolate immutability of the master.