Binding subcomp to child/ren

According to the docs, the shorthand notation for defining components consists in using ComponentType as the xml-element name instead of <Component type=...>:

[...] Once the units are available it is possible to define a component. There are two equivalent ways of doing this: either by using the Component element and setting its type, or by using the type as a new XML element [...]

In the same example, though, we find

<HHGate id="n" power="4">          
   <Forward type="HHExpLinearRate" rate="0.1per_ms" midpoint="-55mV" scale="10mV" />          
   <Reverse type="HHExpRate" rate="0.125per_ms" midpoint="-65mV" scale="-80mV" />      
</HHGate> 

Where <Forward> and <Reverse> are not Component Types (they even have a type attribute), but the name attribute of a Child definition in the ComponentType:

<ComponentType name="HHGate">      
   <Parameter name="power" dimension="none" />       
   <Child name="Forward" type="HHRate" />      
   <Child name="Reverse" type="HHRate" />    

In this case, <HHGate> would have two <Child> of type HHRate, and the element name is being used to determine which is which.

One can always argue that <X name="aX"> is nicer to type than <Component type="X" name="aX">, but being able to bend the rules again and use <aX> (if and only if it is a <Child>) seems abusive to me. Consistence is not only good for us writing parsers/interpreters -- which will have a lot of ad-hoc checks to cope with those special cases -- but for users as well, as changing notation in "magic" places tends to be confusing and frustrating.

Keeping the discussion here in mind, I suggest (@robertcannon) to stick to the <X name="aX"> notation (even though I'd like to be radical on the consistency side and abolish the shorthand notation altogether...).

@pgleeson will probably say we have to live with it since it is used all around NeuroML2 - but actually, this seems to be the case (multiple <Child> with the same type) only for Gate opening / closing rates.

Start with the linked example1 documentation and the discussion in org.lemsml.model issue 2, then inspect the parser or interpreter entry points handling Component and Child XML elements. The issue needs a decided, consistent rule for child binding before implementation can be considered done.