In coming up with a name for the element to reference the Structure and Property Layers from the State Layer analogous to Definition in the Structure Layer (I was thinking of things like Instance), I thought that perhaps we could simplify it to just use Reference for any sort of reference to another object and drop the Definition and Prototype elements. e.g.
<DynamicsProperties name="IzhikevichBursting">
<Reference url="http://nineml.net/catalog/2.0/izhikevich2003.xml">Izhikevich2003</Reference>
...
</DynamicsProperties>
since it doesn't really matter at this stage whether Izhikevich2003 is an abstraction layer Dynamics definition or another DynamicsProperties object. It could also simplify the parsing a little I think if you only have one lookup mechanism to handle.
One side effect of this would also open up the possibility of nesting abstraction layer definitions inside Structure/Property Layer objects e.g.
<DynamicsProperties name="IzhikevichBursting">
<Dynamics>
<Parameter name="a" dimension="voltage"/>
...
</Dynamics>
...
</DynamicsProperties>although I am not sure whether this is desirable or not.
Finally, in a small stylistic change (that I can take or leave) I was thinking that instead of referring to the name of the object in the body of the Reference element, it would fit better with non-XML representations that don't have a concept of a body to move the name to an attribute of the reference, e.g.
<Reference name="Izhikevich2003" url="http://nineml.net/catalog/2.0/izhikevich2003.xml"/>
In coming up with a name for the element to reference the Structure and Property Layers from the State Layer analogous to
Definitionin the Structure Layer (I was thinking of things likeInstance), I thought that perhaps we could simplify it to just useReferencefor any sort of reference to another object and drop theDefinitionandPrototypeelements. e.g.since it doesn't really matter at this stage whether Izhikevich2003 is an abstraction layer
Dynamicsdefinition or anotherDynamicsPropertiesobject. It could also simplify the parsing a little I think if you only have one lookup mechanism to handle.One side effect of this would also open up the possibility of nesting abstraction layer definitions inside Structure/Property Layer objects e.g.
although I am not sure whether this is desirable or not.
Finally, in a small stylistic change (that I can take or leave) I was thinking that instead of referring to the name of the object in the body of the
Referenceelement, it would fit better with non-XML representations that don't have a concept of a body to move the name to an attribute of the reference, e.g.