Loading...
Searching...
No Matches
doc_name_attribute Class Reference

## Detailed Description

  In SBML Level 3 Version 2, the "id" and "name" attributes were moved to SBase directly, instead of being defined individually for many (but not all) objects. LibSBML has for a long time provided functions defined on SBase itself to get, set, and unset those attributes, which would fail or otherwise return empty strings if executed on any object for which those attributes were not defined. Now that all SBase objects define those attributes, those functions now succeed for any object with the appropriate level and version.

The "name" attribute is optional and is not intended to be used for cross-referencing purposes within a model. Its purpose instead is to provide a human-readable label for the component. The data type of "name" is the type `string` defined in XML Schema. SBML imposes no restrictions as to the content of "name" attributes beyond those restrictions defined by the `string` type in XML Schema.

The recommended practice for handling "name" is as follows. If a software tool has the capability for displaying the content of "name" attributes, it should display this content to the user as a component's label instead of the component's "id". If the user interface does not have this capability (e.g., because it cannot display or use special characters in symbol names), or if the "name" attribute is missing on a given component, then the user interface should display the value of the "id" attribute instead. (Script language interpreters are especially likely to display "id" instead of "name".)

As a consequence of the above, authors of systems that automatically generate the values of "id" attributes should be aware some systems may display the "id"'s to the user. Authors therefore may wish to take some care to have their software create "id" values that are: (a) reasonably easy for humans to type and read; and (b) likely to be meaningful, for example by making the "id" attribute be an abbreviated form of the name attribute value.

An additional point worth mentioning is although there are restrictions on the uniqueness of "id" values, there are no restrictions on the uniqueness of "name" values in a model. This allows software applications leeway in assigning component identifiers.

Regardless of the level and version of the SBML, these functions allow client applications to use more generalized code in some situations (for instance, when manipulating objects that are all known to have names). If the object in question does not posess a "name" attribute according to the SBML specification for the Level and Version in use, libSBML will not allow the name to be set, nor will it read or write "name" attributes for those objects.