Thanks Tom, This is a point for which I have no comments :) Kind regards Seref
On Wed, Nov 26, 2008 at 9:27 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Just one small problem - the built RM instance structure usually > deviates in some way from the archetype structure, e.g. the archetype > might have a single EVENT node that stands for any number of EVENTs; the > data may have EVENTs at 0, 5min, 10min, ..... The same goes for most of > the repeated structures in the reference model - the archetype may only > have one or a few 'models' of what the data should look like, while the > actual data may have many. > > - thomas beale > > > Seref Arikan wrote: > > Hi Hugh, > > I am not in my brightest state of my mind at the moment, so I may deny > > that the following belongs to me when I wake up in the morning... > > I think I can build a GUI automatically without instantiating a single > > RM class at all. The reason is; the archetype gives you all the > > information about the types you'd expect from input. The mappings from > > constraints to GUI elements is mostly a one time job: coded text to > > combo boxes, free text to text boxes, duration to some more > > specialized widget, amount to a textbox with a combobox for unit > > etc... (this is pretty much what Ocean's archetype editor seems to do, > > but of course the classes in that source code are not as well > > seperated as the java ref impl) > > Whatever the value is given, the input from GUI can be validated via > > AOM instances, right? I know the constrained RM type in AOM, I know > > the constraints is must satisfy. So the moment I'd create the > > instances would be after gui generation, data input, and validation > > via AOM instances. At that time I have constraint fullfilling data > > which can nicely be placed in a RIM instance. > > For persistence, the archetype is still the deriving force, since to > > create a structured set of RM instances, you need the AOM tree anyway, > > because that's where the structure is, and since every node in AOM has > > its path, a tree with (node, value.toString()) tuples is all I need > > for simple persistence :) > > So, with some extra coding, It seems possible to parse an archetype, > > generate a gui, validate input and save data without using RIM > > classes. I'm not saying that this is the right way to do it, it is > > just that the role of the RM classes seem to begin "mostly" when you > > start coding business logic. Again this is about the java ref. impl. > > Other implementations may assign more behaviour to RM classes. The > > feeling I get is, the whole thing is really archetype driven (and is > > it not the point anyway?) > > > > Many thanks for the feedback, and I hope I did not confuse anyone... > > > > Kind regards > > Seref > > > > > > On Tue, Nov 25, 2008 at 10:20 PM, Hugh Leslie > > <hugh.leslie at oceaninformatics.com > > <mailto:hugh.leslie at oceaninformatics.com>> wrote: > > > > Hi Serif > > > > I would have thought that if you wanted to persist data and > > retrieve it so that it conformed consistently with the archetype, > > then you would have to invent some model of persistence which > > would have at least some if not all of the characteristics of the > > RM - so why not use the RM! You even said that you are parsing > > the archetype and building instances of the RM datatypes in memory... > > > > Not sure how you would do it otherwise as the archetype is just a > > model of constraint on the RM ie when we are building forms for > > instance, the widgets conform to not just the archetype, but also > > the underlying RM and are really archetype constrained versions of > > RM instances but in a GUI model. ie. A quantity for systolic > > blood pressure on the form is a quantity widget that conforms at > > some level to the RM but is constrained by the archetype to mean > > systolic with units mmHg and range 0 to 1000 etc. > > > > regards Hugh > > > > Seref Arikan wrote: > >> Hi Tom, > >> Thanks for the correction of the term. Yes I'm referring to > >> runtime usage of archetypes. > >> After taking a look at the RM class code in ref. impl. I guess it > >> is safe to say that some RM classes seems to check for proper > >> values, and that's a reason to create instances of them. I guess > >> this is where syntactic checks about captured data are done. > >> Also almost any business logic written against the reference > >> object model would require interfaces of these classes, so their > >> instances would be needed in any case you have data to process, > >> so even if I could avoid them for a very simple case, I'd need > >> them again for making any use of data in software. It takes some > >> coding to see their use :) > >> > >> Thanks for the response. > >> > >> Kind regards > >> Seref > >> > >> On Tue, Nov 25, 2008 at 5:43 PM, Thomas Beale > >> <thomas.beale at oceaninformatics.com > >> <mailto:thomas.beale at oceaninformatics.com>> wrote: > >> > >> > >> 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 > >> <mailto: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/> > >> > >> > >> * > >> * > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> <mailto:openEHR-technical at openehr.org> > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > >> > >> > ------------------------------------------------------------------------ > >> _______________________________________________ openEHR-technical > >> mailing list openEHR-technical at openehr.org > >> <mailto:openEHR-technical at openehr.org> > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > >> > >> > >> > >> __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3639 (20081125) __________ > >> > >> The message was checked by ESET NOD32 Antivirus. > >> > >> http://www.eset.com > >> > > > > -- > > > > ________________________________________________ > > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > > Clinical Director > > Ocean Informatics Pty Ltd > > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com > > <mailto:hugh.leslie at oceaninformatics.com> W: > > www.oceaninformatics.com <http://www.oceaninformatics.com> > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org <mailto:openEHR-technical at > > openehr.org> > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/> > > > * > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081126/8868b923/attachment.html>
