Dealing with Attribute Definitions with “Similar” Structure
SMTK’s current Attribute Resource supports the idea of inheritance between Attribute Definitions. This provides the following capabilities:
- Modeling an “isA” relationship between Definitions
- Ability to “share” common item definitions between 2 related Attribute Definitions.
Lets assume we have the following:
- Definition A
- Has category CFD
- Has Item Definition Ia
- Definition B
- Derived from A
- Has category Heat Transfer
- Has Item Definition Ib
If I create an Attribute b from Definition B I would get the following:
- Item Ia belonging to category CFD
- Item 1b belonging to category CFD or Heat Transfer
One shortcoming of this approach
As you can see the Item Definitions inherited by B are not effected by B’s categories. This category isolation was intentional to prevent derived Definitions changing the information classification of the Base Definition. In the example above, it is not desirable for the categories of Ia to be dependent on the Definitions using it. I’m not saying there are no use cases where you would want this behavior, its just not currently supported.
What if instead of an “isA” relationship, you wanted to model a “hasA” relationship. In this case there is no “base” Attribute Definition being used to derive the Attribute Definition.
Item Defintion Blocks
Instead of using Definition Inheritance, this approach would “instance” a block of Item Definitions into an Attribute or Item Definition.
The main goal of this approach is to reduce the need of explicitly copying Item Definitions within the XML file. Therefore the SMTK Attribute Resource would not need to know about them.
Assumptions
- Item Definitions in the Block are added atomically (meaning the order of the Item Definitions in the block can not be changed
- Blocks are only known at File Scope. This implementation would not support having Blocks defined in one SBT file and used in another.
- Item Definitions in the Block can not be “modified” when they are instanced in the target Definition. For example, you could not change the name of the instanced Item Definition. However, categories inheritance from the target Definition would occur.
Possible Format
<ItemBlocks>
<Block Name="B1">
<ItemDefinitions>
<String Name="s1">
<Categories>
<Cat>Solid Mechanics</Cat>
</Categories>
<Int Name="i1"/>
</ItemDefinitions>
</Block>
</ItemBlocks>
<Definitions>
<AttDef Type="Type1">
<Categories>
<Cat>Fluid Flow</Cat>
</Categories>
<ItemDefinitions>
<Double Name="foo"/>
<Block Name="B1/>
<String Name="bar"/>
</AttDef>
<AttDef Type="Type2">
<Categories>
<Cat>Heat Transfer</Cat>
</Categories>
<ItemDefinitions>
<Block Name="B1/>
<String Name="str2"/>
</AttDef>
</Definitions>
In the created Attribute Resource we would have the following:
- Definition Type 1 (Solid Mechanics or Fluid Flow)
- Items
- foo (Fluid Flow)
- s1 (Solid Mechanics or Fluid Flow)
- i1 (Fluid Flow)
- bar (Fluid Flow)
- Items
- Definition Type 2 (Solid Mechanics or Heat Transfer)
- Items
- s1 (Solid Mechanics or Heat Transfer)
- i1 (Heat Transfer)
- str2 (Heat Transfer)
- Items
Note Since the item names can not be changed at this stage. You can not include the same block in both a Definition and in a Definition derived from it since this would cause a name collision.