access on items in a cluster

Technical (archive)
1

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

2

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

3

Hi Georg,

ITEM is an abstract type. The hierarchy pattern of ITEM / CLUSTER / ELEMENT is one of the most common in class modelling.

  • thomas
4

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