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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081119/67962873/attachment.html>
