# ObjectReference
**URL:** https://discourse.openehr.org/t/objectreference/14669
**Category:** Reference Implementation: Java (archive)
**Created:** [4 October 2007 09:00 UTC](https://discourse.openehr.org/t/objectreference/14669 "2007-10-04T09:00:06Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [4 October 2007 09:00 UTC](https://discourse.openehr.org/t/objectreference/14669/1 "2007-10-04T09:00:06Z")
Hi,
It is a bit of theoretical question
_(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. )_
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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [4 October 2007 09:36 UTC](https://discourse.openehr.org/t/objectreference/14669/2 "2007-10-04T09:36:56Z")
(excuse me, there was an error in my previous mail)
Hi,
It is a bit of theoretical question
_(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. )_
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
```auto
```
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [18 October 2007 13:49 UTC](https://discourse.openehr.org/t/objectreference/14669/3 "2007-10-18T13:49:44Z")
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
>
> _(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. )_
>
> 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
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [18 October 2007 20:58 UTC](https://discourse.openehr.org/t/objectreference/14669/4 "2007-10-18T20:58:47Z")
> 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
thanks
Bert
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [19 October 2007 08:09 UTC](https://discourse.openehr.org/t/objectreference/14669/5 "2007-10-19T08:09:28Z")
> > 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
---
### Author:  [@Humberto\_Naves](https://discourse.openehr.org/u/Humberto_Naves)
#### Post date: [23 October 2007 01:39 UTC](https://discourse.openehr.org/t/objectreference/14669/6 "2007-10-23T01:39:56Z")
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
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [23 October 2007 11:25 UTC](https://discourse.openehr.org/t/objectreference/14669/7 "2007-10-23T11:25:39Z")
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
---
### Author:  [@Humberto\_Naves](https://discourse.openehr.org/u/Humberto_Naves)
#### Post date: [24 October 2007 00:51 UTC](https://discourse.openehr.org/t/objectreference/14669/8 "2007-10-24T00:51:40Z")
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