Add support for namespaces in database

Tom Browder — Thu, 13 Jan 2011 15:41:39 -0000

For my own use I have started using the attr feature to add a "{namespace} {Mantech}" attribute pair to the _GLOBAL object as well as other useful attributes. The namespace let's my TGM users know to expect certain attributes on objects, etc. For instance, old TGMs used material codes from PDAM or COVART. I use _GLOBAL to add an attribute pair "{material_codes} {COVART}" or ""{material_codes} {PDAM}" to let the user know what the material codes are. More modern practices use attributes on objects, e.g., "{MUVES_component}", and for our vulnerability tool VALUE on each region I use, e.g., "{VALUE_material} {STEEL}" instead of a material code.

The capability to use multiple namespaces could be done now i believe through a system where one would use something like "{namespace}{mt}" to indicate all unqualified attributes are from the "mt" namespace--no registration needed EXCEPT all hard-wired BRL-CAD attributes would have to have something like "std:" as a prefix. e.g., "std:region" or "std:material_t". Then the default namespace would be "{namespace}{std}", even if not explicitly shown on _GLOBAL.

On a voluntary basis, user namespaces could be registered along with any attributes registrants would like to be to made public. BRL-CAD would incorporate such data into its libraries and provide an API to extract the data for use.

The minimum feature that would need to be done first is to provide a minimal set of registered attributes in the "std" (default) namespace and an API to access them.

Recent changes to 121: Add support for namespaces in database

Add support for namespaces in database