Ok, thanks for the clarification. Heath On 23/03/2012 10:28 PM, "Seref Arikan" <serefarikan at kurumsalteknoloji.com> wrote:
> 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 >> > > > _______________________________________________ > 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/20120324/836e7eb0/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/20120324/836e7eb0/attachment-0001.jpg>
