String IDs

Most GSA objects can have an associated string ID (sID). Typically these are used to associate GSA objects with other objects, whether GSA or third party.

An example of the use of sIDs in GSA is when importing a Revit model - the Revit object id is assigned to the corresponding member's sID.

GSA objects that cannot have sIDs assigned are:

• Specification modules
• Result modules

Loosely speaking, a string ID is a string and it is up to the author, or authoring application, to devise a syntax for the string that makes sense to the author. However, there will be a rapid decline to mayhem if some rules in the use of sIDs are not adhered to.

Rules in the use of String IDs

• The typical format of a sID is a ‘tag, value’ pair, enclosed by curly braces. e.g. "{tag:value}"
• An object may have several ‘tag, value’ pairs, possibly written by different authoring applications. e.g. "{tag1:value1}{tag2:value2}{...}"
• ‘tag, value’ pairs may be nested. e.g. "{tag1:value1}{tag2:value2}{tag3:{sub-tag1:sub-value1}{sub-tag2:sub-value2}...}"
• An authoring application will devise a sID tag that will stand a good chance of being unique. e.g. "MyApp"
• Nested ‘sub-tag, sub-value’ pairs are owned by the authoring application of the enclosing tag.
• It is the duty of the authoring application not to destroy or corrupt any sID ‘tag | value’ pairs not written by itself.