# Extending ReferenceItem

**URL:** https://discourse.kitware.com/t/extending-referenceitem/605
**Category:** Simulation Modeling Toolkit (SMTK)
**Created:** [February 10, 2021, 2:58pm UTC](https://discourse.kitware.com/t/extending-referenceitem/605 "2021-02-10T14:58:21Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Bob\_Obara](https://discourse.kitware.com/user_avatar/discourse.kitware.com/bob_obara/32/37_2.png) [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [February 10, 2021, 2:58pm UTC](https://discourse.kitware.com/t/extending-referenceitem/605/1 "2021-02-10T14:58:21Z")

</div>

The idea is to provide ReferenceItem functionality similarly to discrete ValueItem in terms of optional children.

## Review of Discrete Value Items

- The item Definition includes the following:
  - A list of Item Definitions that represents the children items of the Discrete Item
  - A mapping between the Item’s discrete values and subsets of the children items

- The set of active children corresponds to the current value of the discrete item

## Extending this Functionality to ReferenceItem

- Assume that, similar to discrete ValueItem Definitions, a Reference Item definition would have a set of children Item Definitions.
- Similar to discrete Value Item, the ReferenceItem would contain a map. But in this case its a mapping between PersistentObject queries and subsets of the children items.
- The set of active children would correspond to which query in the map, the current item’s value matches.

So consider the following example:

Definitions:

- GenericMaterial
- LiquidMaterial : GenericMaterial
- SolidMaterial : GenericMaterial
- Void : GenericMaterial

Lets assume we have a Reference Item that can be assigned to GenericMaterial, but have the additional requirements:

- if LiquidMaterial - Additional children are:
  - Initial Flow Rate
  - Initial Temperature

- if SolidMaterial - Additional children are:
  - Initial Temperature

- if Void - no additional children

## API Changes

### ReferenceItemDefinition (additions);

- setContinuousMatching(bool); // Should all conditionals be checked
- bool continuousMatching() const;
- std::size\_t numberOfChildrenItemDefinitions() const;
- bool hasChildItemDefinition(const std::string& itemName) const;
- bool hasChildItemDefinition(const std::string& valueName, const std::string& itemName);
- bool addChildItemDefinition(smtk::attribute::ItemDefinitionPtr cdef);
- bool addItemDefinition(smtk::attribute::ItemDefinitionPtr cdef);
- template typename smtk::internal::shared\_ptr\_type::SharedPointerType addItemDefinition(const std::string& idName);
- int addConditional(const std::string& resourceQuery, const std::string& componentQuery, const std::vectorstd::string& itemNames);
- std::vectorstd::string conditionalItems(int index) const;
- std::size\_t numberOfConditionals() const;

### ReferenceItem (additions)

- std::size\_t numberOfChildrenItems() const;
- std::size\_t numberOfActiveChildrenItems() const;
- smtk::attribute::ItemPtr activeChildItem(int i) const;

## XML Format

```xml
        <Component Name="material" EnforceCategories="true">
          <Accepts>
            <Resource Name="smtk::attribute::Resource" Filter="attribute[type='material']" />
          </Accepts>
          <ChildrenDefinitions>
            <Double Name="velocity" NumberOfRequiredValues="3"/>
            <Double Name="temp"/>
          </ChildrenDefinitions>
          <ConditionalInfo>
            <Query Filter="attribute[type='solid_material']">
              <Items>
                <Item> temp </Item>
              </Items>
            </Query >
            <Query Filter="attribute[type='liquid_material']">
              <Items>
                <Item> velocity </Item>
                <Item> temp </Item>
              </Items>
            </Query >
          </ConditionalInfo>
        </Component>

```

### Related GitLab Info

- Issue: [https://gitlab.kitware.com/cmb/smtk/-/issues/408](https://gitlab.kitware.com/cmb/smtk/-/issues/408)
- Merge Request: [https://gitlab.kitware.com/cmb/smtk/-/merge\_requests/2393](https://gitlab.kitware.com/cmb/smtk/-/merge_requests/2393)

---

<div class="post-metadata">

### Author: ![Bob\_Obara](https://discourse.kitware.com/user_avatar/discourse.kitware.com/bob_obara/32/37_2.png) [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [February 10, 2021, 2:58pm UTC](https://discourse.kitware.com/t/extending-referenceitem/605/2 "2021-02-10T14:58:51Z")

</div>

@chart3388 @johnt @amuhsin FYI

---

<div class="post-metadata">

### Author: ![johnt](https://discourse.kitware.com/user_avatar/discourse.kitware.com/johnt/32/147_2.png) [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [February 15, 2021, 9:37pm UTC](https://discourse.kitware.com/t/extending-referenceitem/605/3 "2021-02-15T21:37:00Z")

</div>

There has been some internal discussion and consensus (I think) that the query elements need to be generalized to support resource or component queries, or both. To do this, here are a couple formatting options to consider.

**1. Use current syntax in ComponentItem**  
e.g.

```auto
<Query Name="smtk::attribute::Resource" Filter="attribute[type='material']" />
// TBD syntax for combined resource & component query

```

**2. Use more descriptive attribute names**  
e.g.

```auto
<Query Resource="smtk::attribute::Resource" Component="attribute[type='material']" />
<Query Filter="smtk::attribute::Resource//attribute[type='material']" />

```

- Each query string has a different name (Resource, Component, Filter).
- In the first example, either Resource or Component can also be omitted if not relevant:

```auto
<Query Resource="smtk::attribute::Resource" />
<Query Component=attribute[type='material']" />

```

**2a.\ Minor variation**

If the general term “Filter” is too non-descriptive, we could also change the element name from Query to Condition to free up “Query”, that is

```auto
<Condition Query="smtk::attribute::Resource//attribute[type='material']" />
<Condition Resource="smtk::attribute::Resource" Component="attribute[type='material']" />
<Condition Resource="smtk::attribute::Resource" />
<Condition Component=attribute[type='material']" />

```

If we were starting from scratch, this would be my preference, but it might cause some heartburn in terms of supporting this in addition to the current smtk query syntax.