incf / nineml-spec

Specification of the NineML model description language.

NineML

Network Interchange for NEuroscience (NineML) is a simulator-independent language with the aim of providing an unambiguous description of neuronal network models for efficient model sharing and reusability (http://nineml.net).

NineML emerged from a joint effort of experts in the fields of computational neuroscience, simulator development and simulator-independent language initiatives (NeuroML, PyNN), grouped in the `INCF Multiscale Modeling Task Force: https://www.incf.org/activities/our-programs/modeling/people`__. This effort was initiated and is still supported by the `Multiscale Modeling Program: https://www.incf.org/activities/our-programs/modeling`__, as part of the standardization effort of the International Neuroinformatics Coordinating Facility (INCF), but the project is now run as a community project.

How to build the source

The source is written in reStructured text and can be build using Sphinx (http://www.sphinx-doc.org/) using the provided Makefile (or the make.bat if on Windows). If you have pip setup you can install sphinx, along with the Read-the-docs theme, with:

$ pip install sphinx sphinx-rtd-theme

HTML

To make the html docs use the command

$ make html

PDF

To make the pdf you will also need a TeX distribution installed (see MacTex on macOS or the texlive-full package on Ubuntu/Debian). After that the PDF can be made with.

$ make latexpdf

Related repositories

In addition to this main NineML repository, which only contains the specification document and XML schema, there are related repositories that are maintained by the NineML team (see http://nineml.net/committee).

• NineML Python Library: A Python library for reading, writing and manipulating NineML descriptions
• `NineMLCatalog`_: A collection of example NineML models serialized to XML.

nineml-spec's Issues

Specific OutputAnalog element instead of using Alias?

This is mainly a stylistic/readability issue, which in most cases will mean just replacing one of the Alias tags with AnalogOut (except when the AnalogPort is connected directly to a state variable when you will need to create an extra tag). However, it would perhaps be useful when it comes to simulator implementation to know which values need to be returned and it should at least help the AnalogOuts visually stand out from the Alias’, of which there could be many.

Specification of subsets

In the version 1 spec, we deferred this to the next version (cf #34)

Add "Constant" tag for numerical constants

In math-inline/mathml expressions, only allow access to parameters/state-variables and aliases not numerical constants with units (dimensionless constants would be permitted to allow 1/exp(-x) and the like). Constants would then be defined through aliases or perhaps it would be better to make an explicit “constant” tag eg.

<Constant name=”Faraday”>
    <Value units=”C/mol”>96485.309</Value>
</Constant>

XML syntax for Projections

This was not fully finalised by the task force. Experience with implementations shows that some further information is needed on how to connect up the ports of the post-synaptic-response and neuron components, and of the plasticity and post-synaptic-response components.

Gap junctions have also not been considered.

Discussion on Index and Property ports

From the dev2.0 spec

Property ports are used in several distinct situations: in order to pass parameters of cells in a population (such as their spatial coordinates) to ConnectionRule or Distribution components, to return properties from Distribution components and to read properties of neighbouring compartments in multi-compartmental models.

and

IndexReceivePorts receive connections from sources that are implicit to the container, whereas IndexSendPorts are used in Distribution
elements used to generate multi-compartmental models.

Does this sound okay?

Moving Ports into Dynamics block within "Interface" element

I have been thinking that maybe the ports should really be part of the dynamics block as they wouldn't make sense for other types of components such as RandomDistribution or ConnectionRule. They are also treated quite differently from parameters so I think it would make sense to separate them.

In some previous versions they sat in an "Interface" element (along with the parameters) which could be reintroduced e.g.

  <ComponentClass name="foo">
    <Parameter name="bar">
    ...
    <Dynamics>
      <Interface>
        <AnalogSendPort name="v" dimension="voltage"/>
        <EventReceivePort name="spike"/>
      </Interface>
      ...
    </Dynamics>
  </ComponentClass>

Other types of ComponentClasses could also use an Interface element for consistency (or the Interface element could just be omitted in both cases) e.g.

  <ComponentClass name="foo">
    <Parameter name="bar">
    ...
    <ConnectionRule>
      <Interface>
        <ReadSourceLayout name="soma_position" attribute="x"/>
        <ReadDestinationLayout name="soma_position"  attribute="y"/>
      </Interface>
      ...
    </ConnectionRule>
  </ComponentClass>

Perhaps such interfaces could also be used to chain together multiple sub-components like we have proposed for dynamic classes.

Allow events to have a scalar value (or potentially multiple scalar values) associated with them

I think this is something that SpineML includes doesn’t it? In the case of incoming spikes, unless you want to create a new synapse component for each connection then you need some way to weight them depending on where they originate from. There may be other use cases as well, for example I think there are recent papers suggesting that the amplitude of certain spikes could effect the post-synaptic response.

Ports need explicit Tag names for validation

The syntax:

<AnalogPort type="xx"/>

can't be validated using standard schemas, these could be moved to:

<AnalogXXPort />

instead.

Allow initial values for state variables to be set internally?

Eg.

<StateVariable name=”m”>
    <Initital><Value>m_inf</Value></Initial>
</StateVariable>

I’m not sure whether this is a good idea or not but when you add the many different states present in biophysically detailed models it would prove a lot of overhead to specify them all at the top level as well as having to duplicate some of the equations.

Adding basic connectivity rules to the core specification

Adding basic connectivity rules such as all-to-all, one-to-one and possibly some random ones along the lines of what is available in PyNN to the core specification to avoid having to deal with namespaces for simple network configurations.

Moving “Property” elements outside of the “properties” tags in component elements

A minor issue that is not really all that important but this just seems unnecessarily verbose to me as well as inconsistent with the way parameters are defined in the component classes.

Add unit-dimension attribute to parameters

Eg. <Parameter name=”g” dimension=”membrane_conductance”/>

Do we want to be able to specify new dimensions (as per LEMS) or simply support a fixed set of dimensions?

Allow meta-data

Allow the definition of meta-data explaining the origins of various components/values of the model

Adding cell layouts to populations or projections

I believe that the layout of cells is a property of the population in both PyNN and SpineCreator. However, it may be better if the cell layouts are provided to the connection generator as required.

Piecewise functions

In the models I am planning to port, piece-wise continuous expressions are required. The subset of MathML that SBML uses has piecewise expressions but since we are not supporting MathML at this stage I have come up with a MathML-like syntax until then, i.e.

<Piecewise name="saturatedVoltage">
  <Piece>
    <MathInline>100</MathInline>
    <Condition>
      <MathInline>v &gt; 10</MathInline>
    </Condition>
  </Piece>
  <Otherwise>
    <MathInline>v * v</MathInline>
  </Otherwise>
</Piecewise>

Within transition blocks, connection rules (see #72) and distribution components (see #63), I don't forsee any issues with piecewise functions, but I am not sure whether they should be allowed within Dynamics blocks, or whether the same functionality could and should be handled by regime changes (my feeling).

Specify units as an attribute of value tag instead of a separate tag

Specify units as an attribute of value tag instead of a separate tag (or should this be a “Quantity” tag instead) eg.

<Value units=”mV”>-50</Value>

Adding explicit initial-states to the component interface.

Adding explicit initial-states to the component interface. This could be in the form of an extra parameter or perhaps an explicit <InitialState> tag.

If initial state values can be defined internally (Issue #9), it might pay to be explicit when the initial state is expected to be set externally. In this case it could just be another parameter, which would make the component interface consistent across different types of components (eg. connection generators, random distributions), but it may make them harder to handle from the simulator design point of view.

Add/edit descriptions of elements in the specification

While the skeleton of the specification is in place (i.e. all members and attributes are present), many sections need filling out with rationale behind the element and what is required to implement them properly.

"RandomVariable"s in transitions, connectivity and distributions

I have been having a look at the way that random distributions are specified in the SBML "distrib" package, and one of the key ways is to simply refer to standard distribution families defined in "UncertML" (http://www.uncertml.org/), which in turn simply provides a description of the distribution (and a link to the wikipedia page). UncertML lists what seems to be a reasonable set of distributions to support:

• BernoulliDistribution
• BetaDistribution
• BinomialDistribution
• CauchyDistribution
• ChiSquareDistribution
• DirichletDistribution
• ExponentialDistribution
• FDistribution
• GammaDistribution
• GeometricDistribution
• HypergeometricDistribution
• InverseGammaDistribution
• LaplaceDistribution
• LogNormalDistribution
• LogisticDistribution
• MixutreModel
• MultinomialDistribution
• MultivariateNormalDistribution
• MultivariateStudentTDistribution
• NegatibeBinomialDistribution
• NormalDistribution
• NormalInverseGammaDistribution
• ParetoDistribution
• PoissonDistribution
• StudentTDistribution
• UniformDistribution
• WeibullDistribution
• WishartDistribution

So I was thinking we could take a similar approach, whereby the onus is on the simulator to implement the distribution (i.e. link to the appropriate scientific math library) (I think this is along the lines of what we discussed when I came to meet you in Paris isn't it Andrew?).

We could still define a component class in the NineML core catalog for each of these distributions (potentially omitting ones we don't feel are necessary at this stage or are difficult to implement), which simply refers to the UncertML description. This should leave the option open to provide general mechanisms for defining more exotic distributions later on if desired.

Preventing valid identifiers from starting and ending with underscores

Not sure if you guys will consider this a bit hackish (or what it implies about the code structure of the reading code), but what do you think of the idea of reserving identifiers that start or end with '_' for internal variables? Just thought it could make implementation a little bit easier from time to time, especially when working with simulators that already have reserved names for things.

"State Layer" to hold initial conditions and snapshots

From discussion at the NineML Standards meeting:

In addition to the parameters defined in the user layer the complete state of model will be defined in a "state layer". States would be defined per component for the components that have states (we are thinking dynamics and plasticity components at this stage), which could look something like

<ComponentState name="initialConditions">
  <ComponentReference url="http:/foo/bar.xml">PyramidalCell</ComponentReference>
  <StateValue name="v">
    <Quantity units="mV">
      <SingleValue>-65</SingleValue>
    </Quanity>
  </StateValue>
  <InRegime>Refactory</InRegime>
  ...
</ComponentState>

This state layer can then be used either to represent the initial conditions of a simulation or save a snapshot of a simulation at a particular point in time.

Allow aliases within Regime elements?

Currently, are aliases only allowed outside regime elements? Would there be some situations where you would want them to be different depending on which regime you are in (when they are connected to an analog port for example)?

Extensions for canonical layouts (syntactic sugar) like NEURON's kinetics syntax

In NEURON, ion channel kinetics can be described in a slightly more canonical form, in which the transitions between markov states are defined rather than the equivalent differential equations for each state. For such cases it would be nice to have a way of extending the XML syntax so that such models can be converted to NineML without losing this structure. Simulator developers could then decide whether to support this syntax natively (as in the case of kinetic equations in NEURON) or "flatten" the canonical XML syntax into its equivalent "base" 9ml.

I think it would be neat if this flattening could be performed by XSLT stylesheets but there may be some cases where we might want a bit more scripting power to perform the conversion.

Partial specifications of component classes

To make it easier to work with component classes with very large numbers of parameters (eg. biophysically detailed neuron models) we could allow "partial specifications" of component classes within the user layer, which could then be used in lieu of component classes in other user layer specifications. The partial specifications would then pass down their parameters to sub-components, enabling the definition of relationships between sub-component parameters, eg.

<ComponentPartial name="AbstractExampleCell">
  <Definition url="http://bar/foo.xml">Izhikevich</Definition>
  <Parameter name="a">
  <Property name="b">
    <Quantity>
      <SingleValue>0.2</SingleValue>
    </Quantity>
  </Property>
  <Property name="c">
    <Quantity units="mV">
      <SingleValue>-65</SingleValue>
    </Quantity>
  </Property>
  <Property name="d">
    <Quantity units="mV">
      <SingleValue>2</SingleValue>
    </Quantity>
  </Property>
</ComponentPartial>

or a model with subcomponents

<ComponentPartial name="Pyramidal_cell">
    <Definition url="http://foo/bar.xml">PyramidalCellContainer</Definition>
    <Parameter name="g_leak" dimension="membrane_conductance">
    <SubComponent name="Na">
      <Property name="gbar">
        <quantity units="uS">0.0036</quantity>
      </Property>
    </SubComponent>
    <SubComponent name="K">
      <Property name="gbar">
        <quantity units="uS">0.0025</quantity>
      </Property>
    </SubComponent>
    <SubComponent name="leak">
      <Property name="g">g_leak</Property>
      <Property name="e_rev">
        <quantity units="mV">-21</quantity>
      </Property>
    </SubComponent>
    ...
</ComponentPartial>

This is also a bit nicer since the distribution of ion channels would be specified at the cell level (as part of the gbar parameter) whereas the kinetics are specified at the ion channel level.

Global "properties"

It has been proposed that it should be possible to define global property values, at the top-level of the NineML description, and to allow derived values (e.g. define total number of neurons and then declare that the number of inhibitory neurone is 0.2 times the total number).

e.g. something like

<Property name="foo">
  <Quantity units="ms">
     <SingleValue>20.0</SingleValue>
  </Quantity>
</Property>

<Property name="bar">
  <Quantity units="ms">
     <MathInline>2 * foo</MathInline>
   </Quantity>
</Property>

Annotation namespaces

It was decided at the NineML meeting in Antwerp to allow all NineML flags to accept "Annotation" elements. These annotations are planned to serve several purposes (among others potentially)

• House comments and meta-data, probably via RDF (see #23)
• Store information about the canonical model in flattened structures
• Provide hints about the structure of the model, which can be used by the simulator to optimise its performance.

We will need to draw up some guidelines/examples on how each of these systems will work.

Connection of ports between any Components

I some circumstances it is useful to connect ports between any pairs of Components. One example is a Dopamine source that is global to the model, but can influence plasticity in several synapses.

Do we want this? It will make implementation more difficult...

Specify class name in definition link (and let the class define its own language)

Eg. <Definition link=”{dir}/classname.xml”>ClassName</Definition>

This format is a little less verbose than the current proposal and also allows multiple classes to be defined within the same file, including the current file (where the link attribute would be omitted). Also, shouldn’t the referencing file be able to specify its own language instead defining it in the definition tag as it is currently (what other languages are we envisioning supporting anyway, NeuroML, SBML)?

Valid parameter ranges?

In the parameter elements of the component class interface, do we want to be able to specify valid parameter ranges?

<Parameter name="gbar" dimension="membrane_conductance">
    <LowerBound><Value units="S/cm^2">0.0</Value></LowerBound>
</Parameter>

Components to define computed properties (eg. distant dependent weights)

In addition to randomly distributed property values, we will need to allow properties that are dependent on other properties of the cell/connection, such as distant-dependent weights.

Referencing components from separate files using a “reference” tag.

Reference components from separate files using a “reference” tag. When referencing components defined in the same file the ref tag could be used without a link or possibly omitted.

<Tag><Ref link=”{dir}/compname.xml”>CompName</Ref></Tag>

or in same file

<Tag><Ref>CompName</Ref></tag> or <tag>CompName</Tag>

Incomplete semantics of Projection objects

The specification currently does not specify the meaning of the Source and Destination fields of Projection objects. Furthermore, the specification would become much clearer if the definition of Projection objects is given in terms of its fields.

"Generator" component classes and property ports

Along the lines of what Ivan was suggesting for the ConnectionRule syntax, combined with my suggestion of a wider variety of ports, what do you think of this proposal for user-defined function components?

<ComponentClass name="myFunc">
  <Parameter name="power"/>
  <Parameter name="scalar"/>
  <ArgPort name="x"/>
  <ReturnPort name="f"/>
  <Function>
    <Alias name="f">
      <MathInline>scalar * x ^ power</MathInline>
    </Alias>
  </Function>
</ComponentClass>

which could then be referenced in another component as

<ComponentClass name="SimpleDynamics">
  <Dynamics>
    <StateVariable name="y"/>
...
    <Alias name="g">
      <Component>
        <Definition>myFunc</Definition>
        <Property name="power">
          <Quantity>
            <SingleValue>2.0</SingleValue>
          </Quantity>
        </Property>
        <Property name="scalar">
          <Quantity>
            <SingleValue>5.0</SingleValue>
          </Quantity>
        </Property>
        <PortConnection name="x">y</PortConnection>
      </Component>
    </Alias>
  </Dynamics>
</ComponentClass>

Thought this format would be general enough that we could even do away with the ConnectionRule and potentially even the RandomDistribution elements. The only problem being that I just realised this is mixing user and abstraction layer components again...

Proposal for generic ConnectionRule syntax

Since this is already written up in the v2.0 spec I sent around I will keep it short here (checkout my dev2.0 branch for the latest version with references to the related github issues).

The list of elements that would be valid within ConnectionRule

• ConnectCondition
• SelectConnections
• Alias
• Constant
• RandomVariable
• Piecewise

of which only ConnectCondition and SelectConnections are specific to connection rules.

ConnectCondition would contain a boolean math-inline expression, which determines whether a source and destination cell are "provisionally" connected (or non-provisionally if there isn't a SelectConnections element). The expression could be dependent on parameters of the ConnectionRule class, random variables, and properties and indices of the cells in the population class via ports. If ConnectCondition is not provided then all-to-all connections are connected.

A subset of the provisionally connected connections (which would be all possible if ConnectCondition is not provided), can be selected via SelectConnections elements. Where a specific number (which can be derived from a random distribution) of connections are made either to a destination cell, from a source cell or in total. Connections can be placed in order of preference via a Preference expression, which evaluates to a real number and is sorted from lowest to highest. Otherwise if Preference is not provided the connections are chosen randomly from the provisionally connected connections.

Explicit connections lists could be passed as a binary mask from a parameter straight into the ConnectCondition, although we would want to have sparse array support for external data files in place for this to be practical.

My thinking is that this should be generic enough to handle most connection rules, and more complex algorithms could be implemented via extensions if required. Let me know what you think.

Adding support for SBML subset of MathML

I have looked into the SBML mathml specification and it seems quite a reasonable subset of operators, which would not be too difficult to support. I have also been playing around with extracting the mathml parser from the libsbml library (C++ with python/java/etc bindings), which is released under the LGPL. It was proving a little tricky so I am considering just re-implementing it in python myself, but I could keep going if it would help add MathML support to other implementations that are written in C++/java though (eg. SpineCreator?).

However, the biggest motivation for adding MathML support would be to add conditionals to the language, so alternatively we could just borrow the MathML way of doing this using (i.e. <piecewise>, <piece> and <otherwise> tags) and not bother about the wider MathML support for now.

Allow sub-components as parameters

This is a bit speculative for now, but basically what I had in mind was to allow components, such as random distributions, to be passed to other components, such as connection generators. Does this make sense?

Specifying dimensions (as in LEMS?)

Since parameter and state variable dimensions have been included into the NineML paper we should decide on a list of acceptable dimensions, and have a means of representing compound dimensions.

LEMS has a method for specifying compound dimensions, which is described in Robert and Padraig's recent paper (see Figure 1B) and also here [http://www.psics.org/lems/example1.html]. I am happy to adopt this approach as it seems a reasonable way to do it and it is nice to keep the two standards as close as possible.

Experiment Layer specification

Alex Cope was saying that SpineML already includes a rudimentary form of this but we may need to make it a bit more rigorous (while just aiming for something relatively modest at this point).

Specification of Sets

Sets are intended to group populations and, possibly, define and group sub-populations. They were not fully specified by the task force.

Array ports to enable components to pass a variable number of parameters between each other.

I am not sure about this to be honest as it could be a bit of a pain to implement but there may be situations where it is necessary. One for the future perhaps...

Extensible parameters for connection lists

Perhaps it would be good if only the delay is included as a required parameter of the connection list and other parameters including weights are extensible.

Allow user-defined functions

I know Ivan is very keen on this feature. I reckon in most cases functions it wouldn’t actually make the component classes much clearer, but in some cases it could come in handy.

If we do add functions, do we want to be able import them from a standard library? This would be convenient from a design point of view and would cut down on duplication but then the component/network definition would no longer be self-contained.

get_or_create_component should inspect component for "type" element

Instead of the subclass of the component being provided to get_or_create_component (in user_layer/components/base.py) the class could be determined by the type of the Dynamics/ConnectionRule/RandomDistribution element within it, allowing transparent duck-typing.

Specification of OnCondition>Trigger expressions

While trying to implement the OnCondition>Trigger block I have realised that its behaviour isn't very well defined in the current specs.

For example, is it possible to specify exact-equality triggers such as v == -20 mV? Since the integration step will almost always jump past such points and some sort of root solver will need to be implemented to see if the exact equality is met unless we assume that the two time points lie on either side of the equality. But in this case, how would == differ from > or < which are triggered once the integration passes through the equality? Do we omit the == and only allow < and >?

If we do omit == we could just specify all triggers as when condition < 0, which would allow us to simplify the syntax e.g.

<Trigger>
  <MathInline>V_threshold - V_membrane</MathInline>
</Trigger>

or for multiple conditions, something like this

<Trigger>
  <LogicalOr>
    <MathInline>V_threshold - V_membrane</MathInline>
    <MathInline>Ca_threshold - Ca_concentration</MathInline>
  </LogicalOr>
</Trigger>

making them easier to parse and implement.

The other issue is the definition of refractory periods. These could always be handled within the condition block but it seems quite clunky to have to define them this way, and they would in any case need to be extracted by the simulator implementation to avoid raising a new event at every time step until the condition is no longer satisfied. So probably a better way is to add an explicit Refractory block in addition to the Trigger block, e.g.

<OnCondition>
  <Trigger>
    <MathInline>V_threshold - V_membrane</MathInline>
  </Trigger>
  <Refactory>
    <MathInline>V_membrane - V_threshold</MathInline>
  </Refactory>
  <EventOut port="outgoingSpike"/>
</OnCondition>

Splitting User Layer into composition and parameterisation layers

The term "User Layer" is a bit loaded as the "user" and what they will want to "use" will vary between applications. Perhaps it would be better to split it into two parts, a composition layer in which all ports and component classes are connected and a parameterisation layer which holds all the parameters of the model. This would have the added benefit of providing a clean interface to model fitting algorithms.

This is related conceptually to issue #36.

Add “type” attribute to component classes

Add “type” attribute to component classes, to specify whether a component is a cell prototype, a connection generator, a random distribution, etc...

<ComponentClass name=”RicianDistribution” type=”random_distribution”>

Add standard library of maths functions

I'm not sure which functions we would want to support and if any of them would fall outside the SMBL subset of MathML

Proposal for multi-compartmental models

I don't have the time at the moment to go into this in as much detail (or with as much thinking through) as I would like but I wanted to get it out there so it has a chance to make the agenda for the upcoming meeting because it will probably require some workshopping.

Building on my last proposal in issue #4 for sub component containers, what do you think of this format?

<ComponentClass name="MultiCompartmentHodgkinHuxleyContainer" type="dynamics_container">
  <Domain name="soma">
    <SubComponent target="Na">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="K">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="leak">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="compartmentBase">
      <PortConnection receiver="membrane_i">
        <Sender component="na" name="i"/>
        <Sender component="k" name="i"/>
        <Sender component="leak" name="i">
      </PortConnection>
      <PortConnection receiver="neighbouring_v">
        <Sender component="compartmentBase" name="v" domain="soma">
        <Sender component="compartmentBase" name="v" domain="dendrites">
      </PortConnection>
      <PortConnection receive="neighbouring_axonal_g">
        <Sender component="compartmentBase" name="axonal_g" domain="soma">
        <Sender component="compartmentBase" name="axonal_g" domain="dendrites">
      </PortConnection>
    </SubComponent>
  </Domain>
  <Domain name="dendrites">
    <SubComponent target="leak">
      <PortConnection receiver="V">
        <Sender component="memb" name="V"/>
      </PortConnection>
    </SubComponent>
    <SubComponent target="compartmentBase">
      <PortConnection receiver="membrane_i">
        <Sender component="leak" name="i"/>
      </PortConnection>
      <PortConnection receive="neighbouring_v">
        <Sender component="compartmentBase" name="v" domain="soma">
        <Sender component="compartmentBase" name="v" domain="dendrites">
      </PortConnection>
      <PortConnection receive="neighbouring_axonal_g">
        <Sender component="compartmentBase" name="axonal_g" domain="soma">
        <Sender component="compartmentBase" name="axonal_g" domain="dendrites">
      </PortConnection>
    </SubComponent>
  </Domain>
  <Compartments xmlns="http://www.neuroml.org/neuromlv2">
    ... compartment specification goes here, potentially using NeuroML2 to specify a 
        predetermined tree or a component specifying an algorithm to generate the 
        compartment tree ... 
  </Compartments>
  <Compartment2DomainMapping xmlns="http://www.neuroml.org/neuromlv2">
    ... again this could be a list of mappings as in NeuroML2/MorphML (I think Padraig
        mentioned a way to ensure the segment groups are exclusive) or an algorithm to
        map the compartments to exclusive domains ... 
  </Compartment2DomainMapping>
</ComponentClass>

In this format, if the "domain" attribute format is not provided to the "Sender" element then the component is in the same compartment, otherwise if the domain attribute is provided, any connections from that domain are connected to the port. This would be a case that would require the array port connections I suggested in issue #13. I am not completely happy with this, particularly having to pass the axonal conductance as a separate port but maybe it is a start that we can work with.

Add unit-dimension attribute to state variables

Eg.

<StateVariable name=”v” dimension=”voltage”>
    <Initial><Value units=”mV”>-65.0</Value></Initial>
</StateVariable>

Multi-component dynamic models

Example:

    <ComponentClass name="Foo">
        <Parameter name="barG" dimension="membrane_conductance"/>
        <Parameter name="C" dimension="membrane_capacitance"/>
        <Parameter name="threshold" dimension="voltage"/>
        <AnalogPort mode="recv" name="celsius" dimension="temperature"/>
        <EventPort name="spike" mode="send"/>
        <Component name="Bar">
            <Definition link="../bar.xml">BarClass</Definition>
            <Property name="g">barG</Property>
            <Property name="e">
                <Value units="mV">-70</Value>
            </Property>
        </Component>
        <Dynamics>
            <StateVariable name="v" dimension="voltage">
                <Initital>
                    <Value units="mV">-65.0</Value>
                </Initital>
            </StateVariable>
            <ComponentDynamics name="BarDyn" component="Bar">
                <ReceivePort name="v">v</ReceivePort>
                <ReceivePort name="celsius">celsius</ReceivePort>
            </ComponentDynamics>
            <Alias name="iBar">
                <ComponentPort compDynamics="BarDyn" port="i"/>
            </Alias>
            <Regime>
                <TimeDerivative variable="v">
                    <MathInline>iBar / C</MathInline>
                </TimeDerivative>
                <OnCondition>
                    <Trigger>
                        <MathML xmlns="http://www.w3.org/...">
                            <gt/>
                            <ci>v</ci>
                            <ci>threshold</ci>
                        </MathML>
                    </Trigger>
                    <EventOut port="spike"/>
                </OnCondition>
            </Regime>
        </Dynamics>
    </ComponentClass>