JavaSIG 2010

1. (from the minutes of the 2010-09 meeting in Rome)
2. JavaSIG 2010 (Davide)
   • Davide: JavaSIG2010 is a revamped version of the old javaSIG material. ItalTBS is serious considering to make this version available to the open source community.
     • This is a javaBeans version of JavaSIG, creating objects with a bean interface instead of POJOs. Datatypes are currently R1, R2 will be taken into account for next version. Map all datatypes to simple database columns.
     • Added useful production information to the base class used by JavaSIG (RimObject)
   • Yeb: one has to be careful when it comes to the Governance of such an open source product: who will be setting the future direction, and how can one guarantee stability and backwards compatibility? Implementers will need to be assured of these things before they decide to use the tool.
   • Discussion: we need to find a couple more interested parties (at least). Victor Chai (Singapore) is one of them.
     • ACTION: Rene to ask DRV Bund (Germany) to verify if they're interested in using the updated version
     • ACTION: Peter Hendler to contact known users of JavaSIG in the US to ensure they know of the new upcoming version and to allow them to express an interest.

From the minutes of the October 2010 WGM (Cambridge):

1. JavaSIG 2010 (Alex Zupan, see http://www.ringholm.de/persist/20101007_RIMBAA_JavaSIG2010.ppt for slides.
   • Proposal/discussion about an updated version of the current JavaSIG toolkit
   • Alex Zupan: This version uses RIM 2.26 and a table per hierarchy PDM approach.
   • Updated the base class with additional attributes; redefine data types - essentially extend the old ones with set/getValue to turn it into a Java Bean. Supports a constrained version of the HL7v3 vocabulary model. Uses lazy loading to a higher degree than the original version - for performance reasons.
   • Peter: does download contain ant target to load demos? Alex: yes. There is a test project which can be made available.
   • Lorraine: What's the supported data type release? Alex: R1.
   • ACTION: reach out to the various e-mail lists (tooling, MnM, RIMBAA, implementation) and ask who has implemented.
   • Position statement by Victor Chai, who could not attend this WGM:
     • Considering that not may people familiar with MIF, and with ongoing change to the MIF, I would think maybe we should consider to use schema based code generation instead of MIF based code generation, I hope this will make the code is easier to read to the general developer community.
     • Possibly use JAXB instead of custom message parsing and building, since JAXB object is generated from the underlying schema, it enables some level of basic conformance mechanism when the JAXB object instance is being populated.
   • Response by Davide Magni, who also couldn't attend this meeting:
     • Use JAXB instead of current way to trasform XML to RIM and viceversa could be an idea to make the code and the procedure more under control
   • Peter: we rejected this, because it creates countless RIM-classes.
   • (statement of clarification received after the meeting took place, and as such this statement is not part of the formal minutes of the meeting):
     • In the beginning of the RIMBAA (then JavaSIG) days, we were looking for a way to create universal applications that would not be restricted to one type of message but could handle any type of RIM message, document or other RIM structure.
     • In the XML ITS the serialized messages, documents and structures are all based on Clone Classes, not RIM classes. If JAXB or any other XML to Java utilities were used, then we would be dealing with Clone Classes of which there are many hundreds or thousands and they are being created all the time. The RIM on the other hand is stable with about 50 classes total. So a database based on the RIM consists of a small finite number of tables, and can take all or any RIM based messages, documents or structures.
     • For these reasons the JavaSIG/RIMBAA work group, which is most interested in applications that are RIM based and not Clone Class based rejected the idea of using JAXB or other similar utilities.
   • Lorraine: when using the RIM ITS this could be a feasible way of doing things.