# ObjectReference

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2007-10-04 09:00 UTC
**Views:** 4
**Replies:** 7
**URL:** https://discourse.openehr.org/t/objectreference/14669

---

## Post #1 by @system

Hi,

It is a bit of theoretical question

*<small>(I haven't looked at the Eiffel-code, because Eiffel does not install and run on any of my Linux-machines, and I hate to change the OS because of the Eiffel-IDE. )</small>*

I have some problem with the reference-objects
So in the Java-code there is not any check at creation of a reference model if the object referring to really exists, also there is no check if the type from the (if existing) object is conform the type of the reffering object. And in locatableref there is even a path-string without check.

This does feel uncomfortable to me, but maybe there are good reasons.

Can someone enlighten this please.

Thanks
Bert Verhees

---

## Post #2 by @system

(excuse me, there was an error in my previous mail)

Hi,

It is a bit of theoretical question

*<small>(I haven't looked at the Eiffel-code, because Eiffel does not install and run on any of my Linux-machines, and I hate to change the OS because of the Eiffel-IDE. )</small>*

I have some problem with the reference-objects
So in the Java-code there is not any check at creation of a reference **object** if the object referring to really exists, also there is no check if the type from the (if existing) object is conform the type of the reffering object. And in locatableref there is even a path-string without check.

This does feel uncomfortable to me, but maybe there are good reasons.

Can someone enlighten this please.

Thanks
Bert Verhees

```

```

---

## Post #3 by @system

Hi Bert,

Sorry for the delay. Please find my comments below.


> (excuse me, there was an error in my previous mail)
>
> Hi,
>
> It is a bit of theoretical question
>
> *<small>(I haven't looked at the Eiffel-code, because Eiffel does not install and run on any of my Linux-machines, and I hate to change the OS because of the Eiffel-IDE. )</small>*
>
> I have some problem with the reference-objects
> So in the Java-code there is not any check at creation of a reference **object** if the object referring to really exists, also there is no check if the type from the

It's not required to perform object existence check by the specs. The reason might be that the object can be maintained by an external system, which makes it too expensive or impossible to validate when the object reference is created.

> (if existing) object is conform the type of the reffering object. And in locatableref there is even a path-string without check.

According to the specs, an empty string is not allowed for path and that check is implemented in the current java code. We could probably do more on path validation, but maybe it's not necessary since there is no guarantee that the path should always be valid.

By the way, it seems that the Class LOCATABLE_REF should be renamed to PATHABLE_REF due to recent extract of Class PATHABLE from LOCATABLE.

Cheers,
Rong

---

## Post #4 by @system

>
> It&#39;s not required to perform object existence check by the specs\. The
> reason might be that the object can be maintained by an external
> system, which makes it too expensive or impossible to validate when
> the object reference is created\.
>
> &nbsp;&nbsp;&nbsp;&nbsp;\(if existing\) object is conform the type of the reffering object\.
> &nbsp;&nbsp;&nbsp;&nbsp;And in locatableref there is even a path\-string without check\.
>
> According to the specs, an empty string is not allowed for path and
> that check is implemented in the current java code\. We could probably
> do more on path validation, but maybe it&#39;s not necessary since there
> is no guarantee that the path should always be valid\.

Thanks for clearing up, these are valid arguments, you give\.
>
> By the way, it seems that the Class LOCATABLE\_REF should be renamed to
> PATHABLE\_REF due to recent extract of Class PATHABLE from LOCATABLE\.

I saw it, I will change it in my next release

thanks
Bert

---

## Post #5 by @system

> >
> > It's not required to perform object existence check by the specs. The
> > reason might be that the object can be maintained by an external
> > system, which makes it too expensive or impossible to validate when
> > the object reference is created.
> >
> > (if existing) object is conform the type of the reffering object.
> > And in locatableref there is even a path-string without check.
> >
> >
> > According to the specs, an empty string is not allowed for path and
> > that check is implemented in the current java code. We could probably
> > do more on path validation, but maybe it's not necessary since there
> > is no guarantee that the path should always be valid.
> Thanks for clearing up, these are valid arguments, you give.
> >
> > By the way, it seems that the Class LOCATABLE_REF should be renamed to
> > PATHABLE_REF due to recent extract of Class PATHABLE from LOCATABLE.
> I saw it, I will change it in my next release

Bert,

I guess you can wait until the RM specs is updated.

Cheers,
Rong

---

## Post #6 by @Humberto_Naves

Hi,

What is the key difference between LOCATABLE and PATHABLE classes? (EVENT_CONTEXT, INSTRUCTION_DETAILS are some examples of classes that are PATHABLE but aren't LOCATABLE)

Is there a real example of an PATHABLE instance that should not be LOCATABLE? In this case, where the paths come from? How may I distinguish different siblings? What is the substitute for the archetype "meaning" (or "node_id") attribute?

Cheers,
Humberto Naves

---

## Post #7 by @thomas.beale

Humberto Naves wrote:

> Hi,
>
> What is the key difference between LOCATABLE and PATHABLE classes? (EVENT_CONTEXT, INSTRUCTION_DETAILS are some examples of classes that are PATHABLE but aren't LOCATABLE)
>
> Is there a real example of an PATHABLE instance that should not be LOCATABLE? In this case, where the paths come from? How may I distinguish different siblings? What is the substitute for the archetype "meaning" (or "node_id") attribute?

as you say, not everything in the RM is LOCATABLE; some things only inherit from PATHABLE, e.g. someof the classes you see here: [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)

PATHABLE means that something is findable using the path routines; LOCATABLE means it carries archetype meta-data nodes, FEEDER_AUDIT etc. Not all information nodes need this.

- thomas

---

## Post #8 by @Humberto_Naves

According to the diagram, the ISM_TRANSITION is not LOCATABLE (but PATHABLE). But the archetype "openEHR-EHR-ACTION.disposition.v1draft" imposes restrictions on a ISM_TRANSITION... So, the question remains:
Should ISM_TRANSITION and other classes be turned LOCATABLE? What is the use of path based routines to find objects that are not LOCATABLE? I just can't figure out...
Thanks in advance,
Humberto

---


**Canonical:** https://discourse.openehr.org/t/objectreference/14669
**Original content:** https://discourse.openehr.org/t/objectreference/14669