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?
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.
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.
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.
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...
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
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...
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.
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.