Hi Seref, I think 'lifecycle' is not the term you want, since most people use that to mean 'authoring lifecycle' i.e. the authoring, review, approval history of an archetype. Here we are talking about the runtime usage of an archetype. If I understand correctly the question it is: can the runtime instantiation of the Java RM objects be avoided in some simple circumstances? It seems unlikely to me, because most of the RM classes have some routines that would be commonly used during data capture, e.g. have a look at the History package in the data structures part of the model - http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html
- thomas beale Seref Arikan wrote: > Hi, > The term lifecycle may not be appropriate for archetypes, and > suggestions for a better term are more than welcommed. > Assuming that we constrain our interest only to a set of information > encapsulated in a single archetype, would you provide the technical > lifecycle you can imagine, for an archetype? The scenario is very > simple: an archetype is loaded from disk, displayed on screen, and > after data is provided by user, data is saved on disk, later loaded > and edited, and saved again. That's it! > > To better explain the context of the question, please think about the > java reference implementation. I'll skip some minor steps and give my > own points, and I'd like to hear yours. > > 1) Archetype is created via a tool like Ocean's designer. > 2) It is loaded by the parser in the java ref. impl. > 3) It's in memory representation is parsed, and know we the > constraints on rim data types expressed in java language terms and > instances of these terms in memory. > 4) Assuming we are creating a gui only for an archetype, we can create > a form using the constraints on data types, and Ocean's tool has an > interface tab that does it. > 5) A user provides information using the generated form. > > 6) We can check the validity of the data entered using the in memory > representation of archetype, like dates, amounts being in allowed > interval, and simply warning user if any data is not valid. > > Things become interesting after this point. In the context of the java > reference impl. and immutable rm classes, we can now create rm > instances since we now have data, and we can persist them. If we were > think of the simplest use case of just storing information and loading > it back, would we need RM instances here? How about saving a custom > represention of user input like an xml file to disk, and reading back > for updates? As long as the link to original archetype is preserved, > updates can be checked for validity. > > In short, I'd be very happy to hear your description of the flow for a > very basic scenario "in the context of java ref. impl". Especially how > you'd use the RM classes (in immutable/mutable form) and when. > > Those of you who are active in development of archetype based systems > can provide very useful feedback for others to follow > > Kind regards > Seref > > Ps( the use of templates is deliberately excluded here, to keep things > within a smaller scope) > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- *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/> * *
