openIDL Navigation
This is a composite decision for different practices adopted for the HDS
The Architecture of openIDL must we well documented in a formal way. Usually, standards organization create a normative document. This document must provide enough information for a reader to understand what is being standardized and enough detail to be used as a guide to understand if the standard is being followed.
sometimes allow null value
sometimes use special value to describe field is null
only use for string fields
do not use for dates, numerics or boolean fields
{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}
Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test}
{example | description | pointer to more information | …}
{example | description | pointer to more information | …}
{You might want to provide additional evidence/confidence for the decision outcome here and/or document the team agreement on the decision and/or define when this decision when and how the decision should be realized and if/when it should be re-visited and/or how the decision is validated. Links to other decisions and resources might here appear as well.}