Though the SBT file format allows a fair amount of flexibility in modeling simulation related information, it tends to be a bit verbose. Specifically, if several items share the same structure, the current implementation requires the designer to replicate each instance. For example if several items represent a 3D vector, the basic structure (such as labels and number of required values, etc…) need to be duplicated. So I propose adding the ability to create item definition templates that can be instantiated in attribute definitions. But in order to provide this functionality we will need to address the current limitation of category inheritance.
Current Category Processing
The following figure show how category information is current associated in an attribute resource:
In the current implementation only non-group item definitions can have category information directly associated with them. This information is then migrated upwards towards the attribute or group item definitions via attribute::Definition::setCategories() and attribute::Item::updateCategories() methods (as shown by the blue arrows). Under normal conditions these methods are used when the attribute::Resource::updateCategories() method is called to determine the categories that are actually used by the resource itself.
There are a couple issues with the current implementation:
- All leaf items typically require categories to be specified on them since there is no way to inherit category information from above. This limitation causes a lot of copying of category information. For example consider an attribute that consists of 10 items and the entire attribute should be consider part of a CFD category. In order to properly model this, all 10 items need to be assign CFD as part of their category information.
- Discrete Items currently do not inherit any of the category information of their children (active or otherwise) and their children do not inherit category information from the Discrete Item. So in order for things to be displayed properly, the template designer needs to copy the information associated with the Discrete Item to its children and make sure to add any unique category information store in its children back to the Discrete Item.
The reason I’m bringing this up in a topic focused on adding Item Templates is that these limitations will impact the usefulness of a template. In order to have the items produced by the template to have the desired category information, the template designer would need to do one of the following:
- Have the template contain the category information explicitly. This will limit the flexibility of the template and still force duplication when the category information needs to change.
- Allow the instantiation of the template to have its own category specification for the top-level item. This will work well for simple templates but not for group items or discrete items with active children.
Proposed Category Processing
What I propose is to allow attributes and all item types to have local category information specified and during the updateCategory process have the information migrate in both directions as shown below:
In this case local category information in initially migrated down towards the leaf nodes (shown by the red arrows) and then back up towards the top (as shown by the blue). There are some cases where a designer may choose for an item not to inherit the categories from it’s parent so I plan on adding a do not inherit property to an item definition. In the figure above, Active Item 7 shows this behavior.
Proposed Template Item Format
<ItemTemplates>
<Double TemplateName="3DVector" NumberOfRequiredValues="3">
<ComponentLabels>
<Label>X Dir</Label>
<Label>Y Dir</Label>
<Label>Z Dir</Label>
</ComponentLabels>
<DefaultValue>0.0</DefaultValue>
</Double>
</ItemTemplates >
Using it would look like this:
<AttDef Type="Foo">
<Categories>
<Cat>Cat1</Cat>
</Categories>
<ItemDefinitions>
<3DVector Name="displacement" Label="Displacement" Optional="true">
<Categories>
<Cat>Cat2</Cat>
</Categories>
</3DVector>
</ItemDefinitions>
</AttDef>
In this example the displacement item would belong to both categories Cat1 and Cat2 and would be optional.