Integer and "sized" Parameters and Property ports

[tclose]

As Paul, Alex and I were discussing in the Gif meeting, with the introduction of Selector and Generator component classes, it will probably necessary to introduce classification of parameters depending on whether they are constant across the container (e.g. the radius of a set of uniformly distributed positions within a sphere) or can vary for each member of the container, as is the case for Dynamics component classes. The "size" of a parameter is also an issue for connection rules, as the parameter may need to be the size of the source container or the destination container. Similarly, PropertyReceivePorts will also need to specify whether they are derived from the size of the source or destination populations.

Therefore, I was thinking that they could both be given an optional size or container attribute to specify whether they are required to be a singleton, the size of the source population, the size of the destination population or the size of the container (either the population or number of connections made). Note that in all cases, a single value can be provided. For example,

<Selector name="FanOut">
  <Parameter name="numConnections" dimension="dimensionless" container="source"/>
  <Select>
    <Number perspective="source">
      <MathInline>numConnections</MathInline>
    </Number>
  </Select>
</Selector

In a related issue, I have been thinking for a while that it would be nice for the size of a population to be passed from a generator, particularly ones that generate the soma layout for example, e.g.

<PopulationProperties name="GranuleCells">
  <Size>
    <FromGenerator port="numberOfCells">
      <Reference>positions</Reference>
    </FromGenerator>
  </Size>
  <CellProperties>
    <Reference>GranuleProperties</Reference>
  </CellProperties>
  <Property name="xPos">
    <FromGenerator port="xPositions">
      <Reference>positions</Reference>
    </FromGenerator>
  </Property>
  <Property name="yPos">
    <FromGenerator port="yPositions">
      <Reference>positions</Reference>
    </FromGenerator>
  </Property>
  <Property name="zPos">
    <FromGenerator port="xPositions">
      <Reference>positions</Reference>
    </FromGenerator>
  </Property>
  <SharedGenerator name="positions">
    <Reference url="http://nineml.net/catalog/2.0/positiongenerators/randomlypackedwithinbox.xml">RandomlyPackedWithinBox</Reference>
    <Property name="minSpacing">
     <Quantity units="um">
        <SingleValue>10.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="xOrigin">
      <Quantity units="um">
        <SingleValue>0.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="yOrigin">
      <Quantity units="um">
        <SingleValue>0.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="zOrigin">
      <Quantity units="um">
        <SingleValue>0.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="xExtent">
      <Quantity units="mm">
        <SingleValue>1.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="yExtent">
      <Quantity units="mm">
        <SingleValue>1.0</SingleValue>
      </Quantity>
    </Property>
    <Property name="zExtent">
      <Quantity units="um">
        <SingleValue>40.0</SingleValue>
      </Quantity>
    </Property>
  </SharedGenerator>
</SelectionProperties>

which could work if the PropertySendPort numberOfCells is of size 'singleton'. However, it would also need to be an non-negative integer value. The requirement of integer values is also an issue for expressions passed to Number elements (e.g. the numConnections parameter in the first example) so perhaps this could be specified explicitly by a 'type' attribute in place of the dimension attribute in both cases.

<Selector name="FanOut">
  <Parameter name="numConnections" type="nonnegative_integer" container="source"/>
  <Select>
    <Number perspective="source">
      <MathInline>numConnections</MathInline>
    </Number>
  </Select>
</Selector

I think it should be possible to extend the dimension checking I have added to the lib9ML library without too much extra work to ensure that parameters/ports of incompatible sizes are not combined and that expressions passed to Number and Size elements are guaranteed to be non-negative integers (either because they are derived solely from non-negative integers or have been passed through rounding functions, i.e. round, ceil and floor).