Overview
The ARM class generator is controlled by an XML configuration file that tells it where to find mapping tables and what ARM definitions to generate classes for. It also has elements that customize the creation functions used for AIM instances and call out collections of AIM instances that should be shared when they appear in mapping paths.
The configuration file contains a single ARM-CONFIG element as described in the following section.
<ARM-CONFIG> element
The ARM-CONFIG element is the root of the configuration file. The following attributes can be given within the ARM-CONFIG tag to describe basic information about the schema and AIM classes.
- workingset
- AIM workingset file used to generate the AIM class library. This also lists the AND/OR combinations available in the AIM.
- aim-schema
- Required, gives the name of the AIM schema which is used to find the compiled EXPRESS dictionary file that the generator should read. The generator needs the EXPRESS data dictionary to understand the structure of the mapping paths. The dictionary filename is constructed by appending "_SCHEMA.stp" to the AIM schemaname.
- aim-schema-dir
- If given, the directory to look for the compiled EXPRESS dictionary file. If not given, the dictionary file should be in the current directory.
- aim-include
- If given, the header file to include for the AIM class definitions. If not given, the header file name is constructed by appending ".h" to the AIM schema name.
- aim-prefix
- Describes the prefix string used by the AIM C++ classes. A prefix given in the workingset file will be used instead if present.
- arm-schema
- A schema name noted as a comment in the P21 header file of ARM recognized data. Not otherwise used.
The ARM-CONFIG element contains one or more mapfile elements which reference external mapping table XML files. It also has one arm-workingset element that contains a list of application object names. An implementation class and any required interface classes will be generated for each one. Finally, there may be aim-type and share elements that give additional details on how to create and share AIM instances.
An outline of a config file is shown below. Refer to each element for more information about its use:
<?xml version="1.0" encoding="UTF-8"?> <ARM-CONFIG attributes> <!-- mapping path definitions" --> <mapfile href="../mappings/ap238/map01.xml" /> <mapfile href="../mappings/ap238/map02.xml" /> ... <arm-workingset> <!-- arm object names, in the order they should be recognized --> ... </arm-workingset> <!-- Default AIM constructor functions --> <aim-type ... /> <aim-type ... /> ... <!-- templates for shared paths --> <share> ... </share> <share> ... </share> ... </ARM-CONFIG>
<arm-workingset> element
The arm-workingset element contains a whitespace separated list of application object names. There should only be one arm-workingset element in the config file. An implementation class and any required interface classes will be generated for each of these application objects.
The application objects will be recognized in the order given. Since each root AIM object can form only one application object, you can use this to prioritize the recognition in tricky cases. The example below shows a few application objects, but the directed angular location dimension application object will be recognized before the more general version.
<arm-workingset> directed_angular_location_dimension angular_location_dimension angular_size_dimension angularity_tolerance </arm-workingset>
<mapfile> element
The mapfile element contains a reference to an external mapping table file as an "href" attribute. Examples are shown below:
<mapfile href="../mappings/ap238/map01.xml" /> <mapfile href="../mappings/ap238/map02.xml" /> <mapfile href="../mappings/ap238/map03.xml" /> <mapfile href="../mappings/ap238/map04.xml" /> <mapfile href="../mappings/common/gdt.xml" />
<aim-type> element
The aim-type element is used to specify a custom constructor function that should be called whenever an instance of that type is needed. The custom function can create contexts, initialize attributes or do other things that are needed for valid AIM data but might not be included in mappings.
The element has two attributes, "type" which gives the entity name, and "pnew" which gives the creator function name.
<aim-type type="representation"
pnew="new_representation" />
<aim-type type="advanced_brep_shape_representation"
pnew="new_advanced_brep_shape_representation" />
<aim-type type="geometrically_bounded_surface_shape_representation"
pnew="new_geometrically_bounded_surface_shape_representation" />
<aim-type type="product_definition"
pnew="new_product_definition" />
<share> element
The share element gives a portion of a mapping path as a CDATA block. Wherever this path is used, the instances will be shared and not duplicated. The first example below states that a product definition will only have a single product definition shape. The second example is similar, and shares a shape_representation and all connecting instances attaching it to a product definition.
<share>
<![CDATA[
product_definition
characterized_product_definition = product_definition
characterized_product_definition
characterized_definition = characterized_product_definition
characterized_definition <-
property_definition.definition
{ property_definition =>
product_definition_shape }
]]>
</share>
<share>
<![CDATA[
product_definition
characterized_product_definition = product_definition
characterized_product_definition
characterized_definition = characterized_product_definition
characterized_definition <-
property_definition.definition
{ property_definition =>
product_definition_shape }
property_definition
represented_definition = property_definition
represented_definition <-
property_definition_representation.definition
{ property_definition_representation =>
shape_definition_representation }
property_definition_representation
property_definition_representation.used_representation ->
representation =>
shape_representation
]]>
</share>