# access on items in a cluster

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2019-10-30 12:26 UTC
**Views:** 2
**Replies:** 3
**URL:** https://discourse.openehr.org/t/access-on-items-in-a-cluster/15561

---

## Post #1 by @system

Hello,
I would like to typecheck AQL queries and have some problems doing that:
The items in a CLUSTER are of type ITEM\. If I access myCluster/items\[at0001\]/value, is there any possibility to type\-check the validity of this path without having the concrete archetype definition at hand? Just using the reference model isn't enough for this task, because ITEMs do not have a value\-field\.
How can \(from an object oriented point of view\) the values of the ITEMs be accessed without knowing if it is an ELEMENT ?
Why is there a distiguishment between ELEMENT, ITEM and CLUSTER at all ? If the fields "items" and "value" were already attached to the class ITEM it would be easier\.
Greetings
Georg

---

## Post #2 by @Seref

Hi Georg,

See inline


> Hello,
> I would like to typecheck AQL queries and have some problems doing that:
> The items in a CLUSTER are of type ITEM. If I access
> myCluster/items[at0001]/value, is there any possibility to type-check
> the validity of this path without having the concrete archetype
> definition at hand? Just using the reference model isn't enough for this
> task, because ITEMs do not have a value-field.
> How can (from an object oriented point of view) the values of the ITEMs
> be accessed without knowing if it is an ELEMENT ?

They cannot be accessed. This is one corner case of two level modelling when it is applied on an RM class that uses a field of abstract type, such as an ITEM.

The archetypes end up setting the concrete type so from a type checking/validation perspective, the fact that a field of type ITEM should have instances of type CLUSTER or ELEMENT are declared by the archetype.

So you cannot check it without using the archetype, or validate it for that matter. You'd actually hit this way up in the RM tree before you make it to types used at the leaves: COMPOSITION has its content field defined as CONTENT_ITEM

There are no perfect design decisions in computer science/engineering, you win some, you lose some. Tom did the right thing by using abstract types when following a OO design for RM. The constraint mechanism (ADL) has to deal with this correct decision, modelling tools then in turn have to deal with this, then AQL validators and programmers who write code against serialised data.

> Why is there a distiguishment between ELEMENT, ITEM and CLUSTER at all ?
> If the fields "items" and "value" were already attached to the class
> ITEM it would be easier.

CLUSTER is a container of actual data, which allows you to represent hierarchical structures. ELEMENT is actual data.

All the use cases and justifications for the composite design pattern apply here, because this is a textbook use of that pattern.

All the best
S

---

## Post #3 by @system

Hi Georg,

ITEM is an abstract type. The [hierarchy pattern of ITEM / CLUSTER / ELEMENT](https://specifications.openehr.org/releases/UML/latest/#Diagrams___18_1_83e026d_1433773264427_531476_6966) is one of the most common in class modelling.

- thomas

---

## Post #4 by @yampeku

Hi Georg,

Seems like you want to validate paths vs the RM. This is doable but probably is easier to use archetypes for that (as every valid archetype path is also a valid rm path). Is there a reason for not using the archetypes? I assume your AQL queries are based on some OPT your system should be aware of.

Regards

---


**Canonical:** https://discourse.openehr.org/t/access-on-items-in-a-cluster/15561
**Original content:** https://discourse.openehr.org/t/access-on-items-in-a-cluster/15561