Specifying extensions

[tclose]

The current text we have for the specification of extensions is

“Extensions” increase the descriptive power of NineML by providing syntax for compact, high-level descriptions of 17 models that can also be expressed in “Core” NineML (i.e. syntactic sugar). Envisaged examples include concise 1 forms for kinetic equations and multi-component/compartment dynamic models.

Core NineML is everything defined by this document, except those parts specifically described as Extensions. To be 1 classified as a NineML Extension, a modelling language must meet the following requirements.

Models written in the Extension format (or part thereof ) must be collapsible to Core NineML without change 3 in behaviour.

1. The flattened (to Core NineML) descriptions must be convertible back to their original form (the additional information required to perform the reverse conversion can be stored in Annotations).
2. Stand-alone tools that perform the two-way conversion between the extended and core forms (preferably written in commonly used languages such as XSLT, Python, Java, etc...) must be downloadable from a publicly available URL (a section of the NineML website, http://nineml.net, is available for this purpose).
3. Non-standard extensions must be defined within a unique namespace
4. Detailed specifications, preferably in the same format as this document (see the ‘ninemlspec.cls’ latex class), must be made publicly available along with the conversion tools.

One of the rationales behind the division between core and extended NineML is to minimise the set of features that a tool needs to support to be NineML compliant, i.e. as long as the core is supported all extensions should also be supported via flattening to core NineML. However, tool builders may want to take advantage of the additional structure provided by the extensions to optimise the implementation of the model or provide more intuitive
interfaces to the user.

Note: To facilitate the reverse conversion from core to extended formats, NineML compliant tools must preserve all annotations during reading, writing and transformation, with the exception of when the return conversion is no longer possible due to the applied transforma- tion or the annotations are explicitly added/deleted by the user.

which I think we are all happy with, but we also need to work out how some of the requirements, such as the conversion tools, are specified.

[NineML-Committee]

Extensions should be specified by a short XML header. Details to be worked out via email