A hole is the absence of a key, which has keys below it, e.\+g. if {\ttfamily some/key} is missing in a property file\+:


\begin{DoxyCode}
some = value
some/key/below = value
\end{DoxyCode}


{\ttfamily some} has a non-\/leaf value. Another example of a non-\/leaf value in X\+ML ({\ttfamily abc})\+: {\ttfamily $<$abc$>$value$<$def$>$value2$<$/def$>$$<$/abc$>$} interpreted by xerces plugin\+:


\begin{DoxyCode}
abc/def = value2
abc = value
\end{DoxyCode}


Config files ideally do not copy any structure if they only want to set a single key.


\begin{DoxyItemize}
\item strongly hierarchically structured data must still be supported
\end{DoxyItemize}


\begin{DoxyItemize}
\item data structure must always be complete
\item prohibit non-\/leaves values
\end{DoxyItemize}

Support holes and values for non-\/leaves in a Key\+Set if the underlying format allows it.

If the underlying format does not support it and there is also not an obvious way how to circumvent it -- e.\+g., J\+S\+ON which does not have comments -- holes and values in non-\/leaves are not supported.


\begin{DoxyItemize}
\item It fits very good to the idea of key-\/value.
\item Some formats support it (e.\+g. X\+ML supports non-\/leaves values; property-\/files support holes).
\item It can be useful for migration purposes, e.\+g. there is {\ttfamily /some/key}, and later {\ttfamily /some/key/enable} gets added. Then it is beneficial if {\ttfamily /some/key} still can hold a value.
\end{DoxyItemize}