Presentation, so the spatial orientation of elements on the screen has always been challenging. Until now, no common standard has emerged to address this, and various providers serving user interfaces approach it in their way. Portability in this field does not exist.

Presentation is closely related to cognition, so the `"mental action or process of acquiring knowledge and understanding through thought, experience, and the senses"`\[[wiki](https://en.wikipedia.org/wiki/Cognition)\]. The presentation comprises activities that are solely human-related. In essence, how a human, using a device with a screen, can benefit from digitalized information or enhance it. Here, the presentation branches to:
1. ability to add new digital information,
2. ability to read digital information.

In 2023, for adding new digital information, we still use forms to capture it from humans. Forms, while still serving their job, are pretty primitive in the sense of how machines could assist humans with intent digitalization that is expressed using words.

The process of form fulfillment expects clear and structured and often categorized answers from the form filler. Its mechanics also depend on how the form elements are arranged within the rectangular area of a device that displays them on the screen. In other words, the arrangement of form elements and their spatial orientation within the available area is often device-dependent or screen size-dependent. No common standard defines how form elements should be displayed on the screen. Depending on the form's complexity and structure (i.e., potential relationships between elements), a columnar approach is widely used where each column serves as the rectangular area for a cohesive part of the form. In many cases, simple/medium complexity forms use one-column approach, where form elements display one after another vertically.

We discussed the side of the capture part of the presentation. However, once the information is captured, several possible approaches exist to display it on the screen for further review or analysis. The spatial arrangement of the information on the screen fundamentally depends on the cognition that is the most "digestable" capability to understand the information. Cognition involves user experience (UX) and user interface (UI) to achieve the most digestable level of information consumability. For digital information that consists of multiple records, tabular representation might be best fit. On the other hand, a single record that expresses a well-known concept from physical space, i.e., a capability like a driving license, digitally can be expressed much like its physical counterpart. Both approaches could apply to the same information but in different contexts. For example, driver's license management might demand tabular representation for a person who manages them. However, for an individual who is the license holder, it is expressed using more visual techniques.

The proposal for ordering OCA attributes is solely a presentation layer concern, so how to display them on the screen. As said above, presentation, so the spatial arrangement of elements within an area, is a difficult topic on its own. The proposal assumes one-dimensional ordering and focuses solely on the `read` part of the digital information. It furthermore does not explain how it eventually converges with layouts and the overall arrangement of elements on the screen that express digital information. In essence, what is the big picture for the general presentation problem as it heavily impacts arrangement and, therefore, also ordering.

Leaving unsolved the arrangement and ordering current and future relationships, it is inevitable to further segregate the overlays according to their belongingness. On the one hand, to isolate and protect what is already there and on the other, to keep smaller cohesive parts responsible for one thing. Therefore, a clear separation of OCA Core (Data Capture Language) from OCA Presentation (Data Presentation Language) is a must-have.

What is also clear is that ordering, as a part of the presentation, shall not become a part of the core. We recommend opening a new family of presentation-related overlays that reflect `Data Presentation Language`. We also recommend introducing explicit ordering by utilizing vectors, where the order of elements in a vector is the canonical order. It primarily simplifies the reading and makes it unambiguous. A hash map, on the other hand, leaves space for ambiguities, i.e.:
`{"lastName": "1", "emailAddress":"3", "phoneNumber": "2"}`
vs.
`{"emailAddress":"3", "phoneNumber": "2", "lastName": "1"}`.

Unless explicitly told, hashes do not preserve the keys' ordering. In the above example, while the end product computed by a machine is the same, it challenges human perception.

We furthermore leave for open discussion a new concept: container. Container is a concept borrowed from UI, encompassing part of the screen, and is embedded into a higher-level concept (row, column, widget -- the name fluctuates across frameworks). Containers address the requirements of arrangement by introducing cohesive parts of elements that are ordered. Containers are an abstract concept and require further work (see below) to dismiss the end-user from manual intervention of how to consume them. Containers also leave space for future enhancements/work related to the overall presentation.

### Final example

{
   "capture_base":"E6dVEHR0obA673USLKJpuvv6qZ9pKnKd-iSCHrsHBue4",
   "type":"spec/overlays/<role> (presentation)/ordering/1.0",
   "containers": {
       "<container label>": [
          "customerID", "firstName", "lastName", "emailAddress", "phoneNumber"
       ],
       "<another container label...>": [ "..." ]
   }
   
}

Fig. Ordering overlay equipped with the recommendations

### Further related work

- Currently, the label overlay contains categories that serve as N-th-level deep sections. These sections are part of the overall arrangement that constitutes the spatial organization of information. Inevitably, a template that is about a spatial arrangement emerges from these considerations. The template splits all available areas into N-th-level deep sections, each displaying a container that preserves the ordering of a cohesive subpart.
- Introduce `presentation base` that look as follows:

  {
    d: "digest",
    bd: "oca bundle digest",
    c: [// containers 
        "container-name-1",
        "container-name-2",
        ...
    ]
  }

By adding a `presentation base,` we properly segregate responsibilities and introduce containers that, by presentation overlays, will get additional characteristics, much like attributes get their characteristics via core overlays.