Hi Heath, Just to clarify: my original issue is not about auto generation of classes from XSD, whether or not one choses to do that is irrelevant if the XSD itself is not supporting generics. The problem is with the XSD (not having support for generics) and it may or may not cascade to programming language space.
Separately, I agree with you on not taking XSD and code generation as the basis of RM implementation, and I am neither following nor suggesting this route. At the moment, I am connecting Rong's implementation to JAXB, which is my choice of design to handle XML related functionality in Java RM. I find these discussions very helpful, even though they have a tendency to fork, but hey, this is why have the groups :) Kind regards Seref On Fri, Mar 23, 2012 at 12:09 PM, Heath Frankel < heath.frankel at oceaninformatics.com> wrote: > I think the topic has drifted slight from Seref's original issue, > although Java nor c# can not implement generics as well as Eiffel or as > intended by the spec author it is possible to get close enough to be > usable. Similar implementation decisions were necessary when specifying the > XML schema and again it is close enough to be usable. > My understanding of Seref's original issue is the auto generation of Java > classes from the XML schema using frameworks like jaxb and .Net. I > personally think this is the wrong way around when it comes to the RM > classes. I know every developer can do it better than the next but any > developer can do it better than a tool. If you are going to invest in > implementing openEHR you should take the time to get a good implentation of > the building blocks by adopting and contributing to an existing > implementation in your preferred language or do it yourself better than > everyone else. > Cutting corners by using a tool will result in you throwing away the > approach and doing it properly later anyway (been there done that). > The only tool that maybe plausible is an openEHR specific class generator > for writing jaxb web services that are driven from AOM, not some generic > XML tool that is not designed to handle the genericity and use of abstract > types as used in openEHR and not able to be expressed in XML schema. > Ocean has been auto generating template data schema and template data > classes for use in working systems for several years, they provide great > benefit but need further work to make the generated artifacts simpler, > flatter and more usable including with tools such as jaxb and mapforce. We > need help to make this happen. > The problem is that everytime we remove complexity we come across a > requirement for the complexity and end up with something closer to the RM > again. > So yes we need to make the entry point to use openEHR lower, but we do > this by comprising the capability of the resulting solution. > > Anyway in conclusion I believe we need to keep the RM specs logical, have > technical specs for serialisation such as XML and ADL, class > implementations in strongly typed OO languages and dynamic languages. > Persistence is another technical group of specs. But I think we should not > mix serialization with class implematation or persistence, except for > stating an anti pattern of using XML tools to generate a class > implementation. > > Heath > On 23/03/2012 12:11 AM, "Seref Arikan" > <serefarikan@?kurumsalteknoloji.com<serefarikan at kurumsalteknoloji.com>> > wrote: > >> I should have been more specific. Generics in collections is a managable >> issue :) and yes, I would not like to go back to non-generic collections >> either.. >> >> >> On Thu, Mar 22, 2012 at 2:26 PM, Thomas Beale < >> thomas.beale@?oceaninformatics.com <thomas.beale at >> oceaninformatics.com>>wrote: >> >>> >>> I have to say, software development would be absolutely dire from my >>> point of view without one particular generic type: Hash<T, K>. That really >>> would destroy nearly every class I have ever written! >>> >>> - thomas >>> >>> >>> On 22/03/2012 01:47, Shinji KOBAYASHI wrote: >>> >>> Hi Peter, >>> >>> 2012/3/22 Peter Gummer <peter.gummer@??oceaninformatics.com> <peter.gummer >>> at oceaninformatics.com>: >>> >>> Shinji KOBAYASHI wrote: >>> >>> >>> Ruby implementation might be one of the proof for replace of generics. >>> I had much struggled to implement generics and got the conclusion >>> that we do not need it. >>> >>> Ruby doesn't have generics at all, right, Shinji? >>> >>> It is right. I felt generics is very convenient, when I used Java, such as >>> >>> Iterator<DvText> it = someRmArrayInstance.iterator() >>> >>> But I found it must be cut off by 'Occam's razor' in Ruby. >>> >>> it = some_rm_array.iterator >>> >>> This code looks curious for Java/Eiffel/C# user who are similar to generics, >>> but it is enough for encapsulated object instance. >>> I think this depends on language environment, but nested generics seems >>> complicated codes for me. >>> >>> List <Map <Integer, String>> >>> >>> Generics is useful to declare what instance is, but it breaks encapsulation. >>> As regards to Bartrand Meyer's paper, 'a good balance' is a good design. >>> >>> Cheers, >>> Shinji >>> >>> >>> There's a comparison of generics and inheritance in an appendix of >>> Bertrand Meyer's "Object Oriented Software Construction", 2nd edition. >>> (http://se.ethz.ch/~meyer/??publications/acm/geninh.pdf >>> <http://se.ethz.ch/%7Emeyer/publications/acm/geninh.pdf> seems to be the >>> original paper that the appendix is based upon.) >>> >>> Generics can be simulated in a language with inheritance, but there is a >>> cost: >>> * Duplication of code. >>> * Extra verbosity. >>> >>> I don't want to have either forced upon me. If I'm unfortunately forced to >>> use a language that doesn't support generics, then I can always simulate it >>> the generics with inheritance. But I certainly wouldn't want the specs to >>> be obfuscated by hacks like that, thanks very much ;-) >>> >>> Peter >>> ______________________________??_________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.??openehr.org <openEHR-technical at >>> lists.openehr.org>http://lists.openehr.org/??mailman/listinfo/openehr-??technical_lists.openehr.org >>> >>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >>> ______________________________??_________________ >>> openEHR-technical mailing listopenEHR-technical at lists.??openehr.org >>> <openEHR-technical at >>> lists.openehr.org>http://lists.openehr.org/??mailman/listinfo/openehr-??technical_lists.openehr.org >>> >>> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >>> >>> >>> -- >>> [image: Ocean Informatics] *Thomas Beale >>> Chief Technology Officer, Ocean >>> Informatics<http://www.oceaninformatics.com/> >>> * >>> >>> Chair Architectural Review Board, *open*EHR >>> Foundation<http://www.openehr.org/> >>> Honorary Research Fellow, University College >>> London<http://www.chime.ucl.ac.uk/> >>> Chartered IT Professional Fellow, BCS, British Computer >>> Society<http://www.bcs.org.uk/> >>> Health IT blog <http://www.wolandscat.net/> >>> * >>> * >>> >>> ______________________________?_________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.?openehr.org<openEHR-technical at >>> lists.openehr.org> >>> >>> http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >>> >> >> >> ______________________________?_________________ >> openEHR-technical mailing list >> openEHR-technical at lists.?openehr.org<openEHR-technical at >> lists.openehr.org> >> >> http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/664fa3c1/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/664fa3c1/attachment-0001.jpg>
