The dependency-types section declares the various types of (elemental) dependency that may occur in the XML data file.
It is perfectly legal for item P to depend on item Q in multiple different ways. For example, a Java method might depend on a Java class several times (e.g. returns, has-parameter, throws, catches, has-local-variable, etc. etc.). Internally, Structure101g will model all these as different dependency types. However, in cases where an elemental dependency is displayed, it needs to pick a single type as the "first choice" and it does this based on the sequence in which the types are defined in the metadata. So where e.g. "returns" is deemed to be more important than "has-param", the "returns" declaration should come first in this section.
Many of the dependencies displayed in Structure101g are virtual. For example, Structure101g would indicate that A depends on X if something in A (e.g. A.B.C) has an elemental dependency on something in X (e.g. X.Y.Z). Pure virtual dependencies (where there is no direct elemental dependency) are always displayed as type "uses". Accordingly, it is good practice never to define an elemental dependency type called "uses".
Here's what the dependency-types element looks like in the example flavor com.headway.examples.xsl:
<dependency-types>
<dependency-type name="includes"/>
<dependency-type name="imports"/>
<dependency-type name="calls-template"/>
<dependency-type name="references"/>
</dependency-types>
Important
Dependency types are modeled internally using an integer bitmask, where some bits are protected. In practice, this means that the number of permitted types is limited to 27.