Notochord ain’t no sorcerer, and it can’t guess how the hierarchy is set. Instead it needs to be told how.
This is done by an xml file: the
Chordata.xml. Apart from containing much of the configuration parameters that can also be passed as command line interface arguments,it contains a description of the hierarchy.
If you want to know exactly how it is defined you can take a look to the
Chordata.xsd file, which is a formal description of the
Chordata.xml file for the purposes of validation.
Whatever hierarchy the configuration file contains, the Notochord reads it on startup, validates it agains tthe
Chordata.xsd file and then parses it creating an internal representation of its contents.
But to better grasp how it works what about some examples?
To describe a hierarchy like this:
The armature part of the xml file would look like this:
<Armature> <K_Ceptor Name="first" id="0"> 3 <K_Ceptor Name="second" id="1"> 0x0f <K_Ceptor Name="third" id="2"> 9 </K_Ceptor> </K_Ceptor> </K_Ceptor> </Armature>
You can see here how the hierarchical nature of the way the K-Ceptors are connected is reflected by nesting XML tags.
Hub and Three K-Ceptors
Let’s take a look to a slightly more complex configuration:
And its xml representation:
<Armature> <Mux Name="main" id="0"> 0x77 <Branch Name="left" id="1"> CH_1 <K_Ceptor Name="first" id="2"> 3 <K_Ceptor Name="second" id="3"> 0x0f <K_Ceptor Name="third" id="4"> 9 </K_Ceptor> </K_Ceptor> </K_Ceptor> </Branch> </Mux> </Armature>
Here we introduced the Hub, which has many gates: Both these elements should be reflected on the xml. While a
<Mux> node can have many
<Branch> nodes inside, only one
<K-Ceptor> is allowed at the first level of each
<Branch> of the