To avoid such problems, gbXML forces the user to select from a list of existing tokensets. However, should the user decide to delete or exclude a tokenset from a language, the prior entry of a tokenset is not affected and could result in a language file definition that contains invalid attributes.

gbXML resolves this problem by checking each validscope and inheritfrom value before creating the language definition file. If the value does not exist, then gbXML does not add the entry to the language definition file.

The incorrect values are kept in the gbXML database in order not to lose the user selection. A user might include/exclude a tokenset multiple time throughout the process of finalizing a language definition, so keeping the invalid references but not writing them into the XML language file prevents the user from having to re-enter a reference multiple times.

The gbXML operations which might cause an invalid validscope/inheritfrom reference are tokenset deletion, renaming of a tokenset, or exclusion of a tokenset (unselecting it from the tokenset list). When one of these actions occurs, and an invalid reference is detected, gbXML will go ahead and write the XML code with those reference removed and change the color of the status label from green to red to acknowledge that the user settings contain invalid references.

The status label is just to the right of the Save button above the XML Code textbox.

To see details on the invalid reference, simply click the status label to enter the 'Validity' debug mode, which will replace the Tokens and Tokens2 textboxes with a single textbox that lists the tokensets where the invalid references occurred.

See the section on Debug Mode for more details.

Invalid Memberlist entries are handled in a similar way. If the user imports, or manually edits a language file and winds up with an invalid memberlist value, the invalid reference is kept in the database but not included in the XML definition code.