Description of problem:
id.value looks redundant for users - admins configuring osinfo. why should they invent new id.value? for me this is useless.

i suppose normal admin would work like this:
* inherit from other definition, he would use derivedFrom.value, define the rest
* (or) create completely new section

so why should he mess with some id.value? should it be unique or if not, would he redefine previously defined data?

this is more troubles than benefit.

and if an admin would not inherit all lines, thus he would not use derivedFrom.value, it should be transparently supplemented by defaults.

right now it looks fragile and not very easy to use.

Version-Release number of selected component (if applicable):
is25

How reproducible:
??

Steps to Reproduce:
1.
2.
3.

Actual results:
fragile, problematic

Expected results:
remove id.value, just use derivedFrom.value to populate data for "missing" keys; it not derivedFrom found, populate from default transparently.

Additional info: