# ResourceDescriptionItem **Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154) **Created:** 2006-10-11 11:12 UTC **Views:** 1 **Replies:** 9 **URL:** https://discourse.openehr.org/t/resourcedescriptionitem/14587 --- ## Post #1 by @system Hi, please allow me a small question\. If you rather see me ask this kind of implementation\-specific questions to the list, I can do that, but for now, I ask you personally I noticed something strange\. Maybe I am wrong, so please explain to me\. I was looking at the code in the sandbox\-branch of the Java\-implementation, and I discovered that the class ResourceDescriptionItem has TerminologyService terminologyService in its constructor\. This property may not be empty\. But I don't find this property used in that class, nor in its anchestor RMObject\. Neither do I see this property mentioned in the documentation or in the Eiffel\-classes\. How can I understand this? Is there a change coming which is not yet announced? Thanks bert --- ## Post #2 by @system Bert Verhees schreef: > Hi, please allow me a small question\. > > If you rather see me ask this kind of implementation\-specific questions > to the list, I can do that, but for now, I ask you personally >   Sorry, I was doubting whether to send it personally to Rong or to the list, now, my cat made the decision by walking over my keyboard\. I don't know what the best policy is\. Thanks Bert --- ## Post #3 by @thomas.beale Bert, I cannot say anything about the Java details, but you can find the specification of these classes in the Support IM \- http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf The classes can be seen also in the online UML \- http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109704455987_448858_7286Report.html and also http://www.openehr.org/uml/release-1.0.1/Browsable/indexLeft.html hope this helps\. \- thomas Bert Verhees wrote: --- ## Post #4 by @system Thomas Beale schreef: > ``` > Bert, > > I cannot say anything about the Java details, but you can find the > specification of these classes in the Support IM - > [http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf](http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf) > > The classes can be seen also in the online UML - > [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109704455987_448858_7286Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109704455987_448858_7286Report.html) > and also [http://www.openehr.org/uml/release-1.0.1/Browsable/indexLeft.html](http://www.openehr.org/uml/release-1.0.1/Browsable/indexLeft.html) > > hope this helps. > > - thomas > > ``` Thanks Thomas, but it does not help, or maybe it does, let me explain. Everything is consistent, except for the java-class ResourceDescriptionItem in the sandbox branch of the Java-implementation. And that makes me wonder, because, Rong just stated, that, even if it is not official, the sandbox is the ongoing work for the 1.0.1 implementation, but I knew before because that is the only spot where updates occur. (maybe there are some more inconsistencies I did not yet found) So maybe your answer does help. If you say, that what is in the documents and in the UML is the offically state of specifications, the one we can trust, than I can regard it as an error in that Java-class, and repair it my self, though I hate working in those classes (I like to see them as reference), I must go on and do more work in there, for the time being. I keep in mind if I don't change the interface, it is easy to reconnect if the classes pickup again with my work. That was why this issue is a problem. This is an class-interface-issue (an extra parameter in the constructor). Too bad Rong does not answer, he is the one who really knows what the problem is. It is a minor question, but programmer's know, even minor issues make compilers stumble. So I repeat my question for clarity: Can I trust the UML link ([http://www.openehr.org/uml/release-1.0.1/Browsable/indexLeft.html](http://www.openehr.org/uml/release-1.0.1/Browsable/indexLeft.html) ) to follow the true and only specifications? Thanks, Bert --- ## Post #5 by @system Hi Bert, The reason for terminologyService to be there is to provide checking of language codePhrase\. There are other classes in the RM that have same use of terminologyService\. Cheers, Rong Bert Verhees wrote: --- ## Post #6 by @thomas.beale Rong Chen wrote: > Hi Bert, > > The reason for terminologyService to be there is to provide checking of > language codePhrase\. There are other classes in the RM that have same > use of terminologyService\. >   yes, this is pretty common in the reference model\. I think the only inheritance we don't bother showing in the online UML or the published PDFs is the inheritance of the ExternalEnvironmentAccess class into classes needing access to the TerminologyService and other similar classes, on the grounds that this clutters the model without really adding any useful information\. Maybe we need to comment this better somewhere\.\.\. \- thomas --- ## Post #7 by @system Rong Chen schreef: > Hi Bert, > > The reason for terminologyService to be there is to provide checking of > language codePhrase\. There are other classes in the RM that have same > use of terminologyService\. >   Thanks, I think I understand, I am confused because it is not part of the specs\. But now I know it is not an error, and I will figure out how it works Bert --- ## Post #8 by @system Thomas Beale schreef: > Rong Chen wrote: >   >> Hi Bert, >> >> The reason for terminologyService to be there is to provide checking of >> language codePhrase\. There are other classes in the RM that have same >> use of terminologyService\. >>   > > yes, this is pretty common in the reference model\. I think the only > inheritance we don't bother showing in the online UML or the published > PDFs is the inheritance of the ExternalEnvironmentAccess class into > classes needing access to the TerminologyService and other similar > classes, on the grounds that this clutters the model without really > adding any useful information\. Maybe we need to comment this better > somewhere\.\.\. >   Ah\.\.\.\., this clarifies it even more Thanks \(commenting it somewhere is very helpful\) Bert --- ## Post #9 by @system Bert Verhees schreef: > ``` > Rong Chen schreef: > > ``` > > > ``` > > Hi Bert, > > > > The reason for terminologyService to be there is to provide checking of > > language codePhrase. There are other classes in the RM that have same > > use of terminologyService. > > > > ``` Rong, I took a look at it, I found in the Eiffel-sources many classes inherit from EXTERNAL_ENVIRONMENT_ACCESS, and are provided in this way in the terminology Service. It is not that I want to criticize, but I want to understand, and anticipate on what will happen in the near future. I found the class ExternalEnvironment, but I did not find any references to it. Do you think this is going to change? I come to the subject because I wanted to get adl.jj to run, and change it to the current situation, and I found the archetypedescriptionitem which has been changed to resourcedescriptionitem, and found it has an extra parameter, an interfaced object, and I did not know how to arrange that in JJ. That is the whole story. I guess I better leave it to you, because it is your plan, and you know what is going to change, and I wait for the result. Have a good time in Switzerland regards Bert Verhees --- ## Post #10 by @system > Bert Verhees schreef: > > > ``` > > Rong Chen schreef: > > > > ``` > > > > > ``` > > > Hi Bert, > > > > > > The reason for terminologyService to be there is to provide checking of > > > language codePhrase. There are other classes in the RM that have same > > > use of terminologyService. > > > > > > ``` > > Rong, > > I took a look at it, I found in the Eiffel-sources many classes inherit from EXTERNAL_ENVIRONMENT_ACCESS, and are provided in this way in the terminology Service. It is not that I want to criticize, but I want to understand, and anticipate on what will happen in the near future. > > I found the class ExternalEnvironment, but I did not find any references to it. > > Do you think this is going to change? > > I come to the subject because I wanted to get adl.jj to run, and change it to the current situation, and I found the archetypedescriptionitem which has been changed to resourcedescriptionitem, and found it has an extra parameter, an interfaced object, and I did not know how to arrange that in JJ. That's the tricky part, see my other email explaining that. > That is the whole story. > > I guess I better leave it to you, because it is your plan, and you know what is going to change, and I wait for the result. Yes, I am in the middle of fixing that right now. I will commit the code after I get back from Esslingen. > Have a good time in Switzerland Thank you! Cheers, Rong --- **Canonical:** https://discourse.openehr.org/t/resourcedescriptionitem/14587 **Original content:** https://discourse.openehr.org/t/resourcedescriptionitem/14587