Re: findMatchingRMClass
Hi All, First of all; I am not a Java programmer. I have been watching this thread and it is confusing the heck out of me. 1) What are these "untyped" dADL files; specifically? 2) I have looked at virtually all of the nearly 1200 ADL files in the openEHR SVN and I do not see anywhere that there is any confusion in the typing of the defined archetypes or the components therein. 3) Bert: I'm not sure where the confusion is but I would suggest staying as close to the SPECIFICATIONS as possible irregardless the Java implementation (if there is a difference). 4) I do not see anywhere in the specifications an attribute called: findMatchingRMClass So; how and where did you come up with this? As we are implementing the specs in Python; you Java guys are scaring me since you have been at this longer than I have and seem to be having strange difficulties. Thanks for the feedback. Cheers, Tim On Sun, 2008-07-27 at 22:08 +0200, Bert Verhees wrote: > > <br> > > I am interested to know what you are using this type matching method > > for - I have never had to write anyhting like this - in our parser > > software, we always know what the type of the object is a > > priori.<br> > > <br> > > There are some untyped dADL-files in the java-project, and I was > wondering > if I should support them, this because I want to stay as close as > possible > to the java-reference implementation. > But supporting them took me already several days, and was unreliable > (in > my case), so I stopped (for now) supporting them, it is very easy to > work > around (just put the types in it). > > Although, there is a problem. Because want to use dadl as a format for > data-transport, for example from an application to the orm layer (also > passing the rm-builder to create RM-types) > This is OK, when I have everything under control, but I want the > kernel I > am writing also to be connectible to software (GUI's, other > data-entry-machines) from third parties, and I want them to use DADL, > but > in that case, the spec, which does not require types is working > against > me. So if this point could be changed in the spec, I would be happy, > but > if it cannot, then I have to live with it (and add an extra > restriction). > > Bert > > _______________________________________________ > Ref_impl_java mailing list > Ref_impl_java@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java -- ************************************************************************** Join the OSHIP project. It is the standards based, open source healthcare application platform in Python. Home page: https://launchpad.net/oship/ Wiki: http://www.openehr.org/wiki/display/dev/Python+developer%27s+page **************************************************************************
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ref_impl_java mailing list Ref_impl_java@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_java