Ime Asangansi wrote: > Thilo and others, > > Thanks for this remarkable and engaging read! > This will come in helpful in the project... > > BTW: This is a really supportive community > > But it will be nice to hear from the guys who did the things you > outlined... > It will be nice to have such a project... it will also be a step > towards a pure full blown open-source openehr implementation > > rgds, > Ime Hi Ime, Thilo and all
We investigated using XForms for automatically-generated data entry GUIs last year. There are some features of XForms which made it seem particularly well suited to the task: a lot of built-in entry data validation, ability to validate data against a schema embedded in the XForms definition, ability to decouple the connection between an input widget and the target item in the schema by using an XForms binding item... not to mention being a completely open, platform-independent and XML-based standard (even if there's very limited browser support thus far), etc. It was a while ago, so I have probably forgotten some other pros. But gradually it came to feel like we were trying to force XForms to do something it is too generic/low-level to be suited to. The main challenges were: 1. The existing XForms implementations were generally immature/flaky or not in line with the latest XForms specification. 2. The openEHR DATA_VALUE types are of a larger grain than most of the XForms widgets, so more than one XForm widget, more than one databinding and more than one binding constraint had to be defined per openEHR ELEMENT. That made the XForms definition very verbose and complicated to read as code. 3. The set of XForms widgets available seemed very limiting when it came to creating graphic entry controls for certain data values or with complex value constraints. For example, we never successfully created a mechanism to populate an externally coded term (would have had to query a terminology web service) using XForms widgets and events. It may be possible, but not at all trivial. 4. It was a particularly challenging task to model the AOM constraints (for each ELEMENT) as XForms binding constraints and so we experimented with adding the value constraints directly as from the AOM schema using the XForms extension module (but this required an XForms engine that could understand the AOM extensions to really test it and no such engine exists.... *yet*) NB: For #4 it doesn't necessarily matter if you don't want to apply/validate the AOM constraints on the client side, but I think it is important in most cases to have these constraints contained and applied in the XForms definition to make it *usable*. What has your experience been Thilo, Ime? What are your thoughts? I am very interested in any work going on in this area! Lisa -- Lisa Thurston Phone +61.8.8223.3075 Skype lisathurston Ocean Informatics Pty Ltd Ground floor, 64 Hindmarsh Square Adelaide SA 5000 http://www.oceaninformatics.com
