WARNING : Work in Progress!

Component Re-use in the Physiome Languages

Currently the three Physiome Languages have different mechanisms for referencing language components that are to be re-used. Examples of some component re-use are given in Figure 1.

The mechanisms for component re-use must be standardised across the languages to minimise the complexity of learning the correct use of these languages, for both those developing software and those entering data. Although they go under a variety of guises in the above examples, there are really only two intended types of re-use here, referncing and copying.

The first is the link, reference and share behaviour of AnatML, FieldML and CellML respectively. The intent is to create a link from the current object to the object referenced. The target is uniquely identified by the combination of its name and (if required) and href. (href was borrowed from the HTML anchor tag, and could conceively contain filename references, web addresses, or database location info.) In addition, the share tags in FieldML contain a rename attribute, which is supposed to signal the processing application that it requires a new instance of the referenced object in memory with the specified name, and this is then shared with all other instances of the object that refer to that name, or which are renamed to that name.

In the second type of component re-use, objects are supposed to be copied from the specified target to the current location (replacing the referencing tag). This type of behaviour is particularly useful in FieldML where a mesh might typically be created by re-using an element multiple times, re-naming each new instance with a unique identifier.

All of the above behaviour can actually be handled with a single tag. Out of the numerous current options, the one which is perhaps most intuitive, and which is the most hassle to change, is the ref method. So any tag which ends in _ref can be treated by the application as a link to an object defined elsewhere. The available attributes are @name_ref, @href, and @rename. Only certain objects will be reference-able in the different languages, allowing DTD-based validation on the types of objects referenced, and the placement of the references. The DTD definition for a typical object-referencing tag from FieldML is shown in Figure 2.

<!ELEMENT  generalized_field_description_ref    EMPTY>
<!ATTLIST  generalized_field_description_ref
    name_ref          CDATA         #REQUIRED
    href              CDATA         #IMPLIED
    rename            CDATA         #IMPLIED>

Note that the tag's content model may not actually be empty, as we will see later. The @rename attribute is not the same as a @name attribute; whereas the latter indicates the name of the current tag, the former indicates the name of the tag which will replace the current tag. ???_ref tags will probably be the only tags in the Physiome Languages to not have @name attributes, and it prevents them from being the targets of references. It also means that if the @rename attribute is used to group references (discussed later), all references should point to the original object, and not the first reference to it, although this might be desirable.

Processing should follow this model (where dataset refers to the unit of information which contains the tag, typically a file):

• The type of object referenced is found by stripping the _ref string of the end of the current tag.
• If the @href attribute doesn't exist, then the value of the @name_ref attribute refers to an object of the specified type within the current dataset with that value in its @name attribute.
• If the @href attribute exists, then its value refers to a dataset external to the current one, and should thus contain both protocol and locator information. Examples are :
  • http://www.physiome.org.nz/data.xml
  • file:/physiome/data.xml (Question - what happens with c: in filenames?)
  The value of the @name_ref attribute refers to an object of the specified type in the specified dataset with that value in its @name attribute.
• If the @rename attribute exists, then the processing application should scan the objects currently in scope for those of the specified type with a @name value equivalent to that in the @rename attribute of the current tag. If such an object exists, the reference should be changed to point to that object. If no such object exists, then one should be created. This means that objects can be duplicated and shared in groups: for example, a CellML <mechanism> might be referenced twice under one name with one set of parameters, and then twice under another name with another set.

An option which is still being considered was to have ??_copy tags in addition to the reference tags. In these tags the @rename attributes would be REQUIRED, making it clear that a new instance of the object referenced would be created for each reference (although using DTD-based validation, there is no way to force each new name to be unique for a particular tag type.) It also makes it clearer (using the DTD) where elements can be referenced and where they can be copied - although the distinction is frequently implentation dependent.

Parameter Passing and Over-riding

Now that we have a way of referencing objects defined elsewhere, we need a facility for setting parameters and over-riding child components. Currently this has only been dealt with properly in CellML, using the <requires>, <import_variable> and <export_variable> elements. An small example of this is given in Figure 3.