# Making Attribute Items Resource Components

**URL:** https://discourse.kitware.com/t/making-attribute-items-resource-components/594
**Category:** Simulation Modeling Toolkit (SMTK)
**Created:** [January 14, 2021, 3:59pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594 "2021-01-14T15:59:44Z")
**Posts on this page:** 6
**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: [January 14, 2021, 3:59pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/1 "2021-01-14T15:59:44Z")

</div>

Currently attribute::Item is not considered a component to an Attribute Resource (only attribute::Attribute is derived from resource::Component). This topic is focused on presenting potential benefits of changing the design as well as attempting to scope out what code changes this would entail.

## Potential Benefits

- Items could be specified/returned w/r Operations
- Reference Items would be explicitly specified in a Resource Link making lookup and conflict resolution easier
- Items could have properties
- Items could be targeted by Reference Items
- Items could be found by UUID
- In the case of supporting active categories, if the resource has a map of all items it could easily traverse it to activate/deactivate Reference Items based on categories.

## Potential Coding Tasks

### Resource Link Usage Changes

- All of the current code that deals with Resources Links at the Attribute Level would need to be pushed down to the Reference Item Level. This could in theory make things cleaner since right now Reference Item has to manipulate the links through its Attribute.

### Attribute Resource Changes

- Need to update Query grammar to include Items and their types (and values??)
- Probably needs to have a map of UUIDS to Items
- Deleting Items will now involve the resource
- Items will have direct access to the resource instead of having to go through its attribute/parent item

### Additional I/O support (XML and JSON)

- Need to store properties on the Items - This is probably easy for JSON since the property system already supports this. Not too sure about XML.
- Need to store the UUID (not too much of an issue though the XML form probably needs to support the case of Items w/o UUIDs - when attributes are being hand written)
- Probably don’t need to change the format version

### Attribute Utility Changes

- Find associatable objects will need to include items

### QT GUI Changes

- qtReference Item will probably need some slight changes.

---

<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: [January 14, 2021, 4:00pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/2 "2021-01-14T16:00:48Z")

</div>

@chart3388 @amuhsin @johnt @dcthomp - FYI

---

<div class="post-metadata">

### Author: ![dcthomp](https://discourse.kitware.com/user_avatar/discourse.kitware.com/dcthomp/32/10_2.png) [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [January 14, 2021, 7:56pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/3 "2021-01-14T19:56:24Z")

</div>

> [@Bob\_Obara](#):
>
> Need to store properties on the Items - This is probably easy for JSON since the property system already supports this. Not too sure about XML.

Adding properties to Item instances will work as soon as Item inherits Component. As long as `smtk::attribute::to_json(json&, const ResourcePtr&)` and `smtk::attribute::from_json(const json&, ResourcePtr&)` call `smtk::resource::to_json(json&, const ResourcePtr&)` and `smtk::resource::from_json(const json&, ResourcePtr&)` in their respective implementations, JSON serialization/deserialization will just work.

Because XML is treated as “import/export” format instead of the native format, it might be acceptable to omit properties when exporting XML – at least initially – since exporting can be a lossy process.

---

<div class="post-metadata">

### Author: ![chart3388](https://discourse.kitware.com/letter_avatar_proxy/v4/letter/c/82dd89/32.png) [@chart3388](https://discourse.kitware.com/u/chart3388)
#### Post date: [January 15, 2021, 3:28pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/4 "2021-01-15T15:28:41Z")

</div>

Can an item be associated to itself? Assume so since an attribute resource can be.

---

<div class="post-metadata">

### Author: ![dcthomp](https://discourse.kitware.com/user_avatar/discourse.kitware.com/dcthomp/32/10_2.png) [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [January 15, 2021, 4:21pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/5 "2021-01-15T16:21:11Z")

</div>

I assume auto-association is about as possible and useful as auto-cannibalism… nothing’s really stopping you, but why?

---

<div class="post-metadata">

### Author: ![chart3388](https://discourse.kitware.com/letter_avatar_proxy/v4/letter/c/82dd89/32.png) [@chart3388](https://discourse.kitware.com/u/chart3388)
#### Post date: [January 19, 2021, 3:01pm UTC](https://discourse.kitware.com/t/making-attribute-items-resource-components/594/6 "2021-01-19T15:01:13Z")

</div>

No use case other than testing pandora’s box.
