Hi Lisa, Thilo et al, Really appreciate your comments... I have the impression that much still has to be done about Xforms... OpenMRS is based on infopath for now, so I am now looking at archetypes as form templates (.xtp files). These are relatively reusable form parts and are analogous to form parts. Beginning to put my thoughts on a blog at asangansi.blogspot.com. Will have to map the datatypes to control types... etc
Ime Thilo Schuler <thilo.schuler at gmail.com> wrote: Hey Lisa, ime et al back from skiing - had 6 sunny days and time. Thanks for the valuable replies. Comments inline... > 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. IBM enlists these reasons for XFrorms: # XForms is a W3C XML Standard; # XForms is XML and submits XML; # XForms uses W3C XML Schema for validation and data integrity; # XForms uses W3C XPath for data references; # XForms is a Model-View-Control (MVC) architecture; # XForms uses W3C XML Events for loose coupling; # XForms can be embedded in other host languages; # XForms rendering is decided "on the glass" (write once, render anywhere); # XForms reduces/eliminates need for scripting; # XForms decreases client/server traffic; and # XForms encodes dependencies in data and validates that data is declaratively and relatively easily. Their XForms <-> DB2 Demos (http://services.alphaworks.ibm.com/DB2pureXMLDemo/) are fascinating but also seem very 'hacky'. Look for example at the HL7 CDA one at http://services.alphaworks.ibm.com/DB2pureXMLDemo/hl7CDAXForms/XFormsDemo.xhtml > > 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. Have gotten better but still don't support the whole XForms 1.1 specs. Especially if you try non trivial stuff the chances for bug increase rapidly > 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. Here encapsulting the code as a custom XBL widget could help -> hides complexity. This would also allow to do hidden (from the XForms markup point of view), well-tested scripting where XForms capabilities are not enough. Here is an example of a simple XBL widget: http://www.ibm.com/developerworks/library/x-xformsrte/ Currently only the Firefox XForms extension and partly the Formsplayer IE-plugin support XBL. And since it hasn't been used much also a good chance of flakyness... Here are two links describing using XBL in the above mentioned XForms engines: http://developer.mozilla.org/en/docs/XForms:Custom_Controls and http://www.formsplayer.com/node/378 > 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. Again a well written and tested XBL custom widget could do the job > 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*) What do you mean by XForms extension module? Do you want to add own elements or attributes (in a separate namespace)? IMO, in such a case you would need to create your own XForms engine (or build on an existing one) that understands these add-ons. This is an example: http://www.fh-oow.de/institute/iapg/personen/brinkhoff/paper/W2GIS2007.pdf > > 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! > I can totally understand your concerns. In this work http://www.ncbi.nlm.nih.gov/pubmed/17108529, I fiddled with too immature XUL and XBL. So with XForms and DB2 I plan to start very modestly (more on a fun basis besides boring exam studying) and see were I am going... Generally I still think a declerative approach is the best option for form generation. Here are two more links regarding XForms forms generation (obviously not as complicated as openEHR forms would be): - http://www.ibm.com/developerworks/library/x-xformsniem/ - http://www.alphaworks.ibm.com/tech/xfg >From a business perspective (ie Ocean) either a stable, reliable technology is needed to get good results in the mid-term or possibly considerable investment in improving the XForms engines needs to be made. What are your plans at Ocean regarding GUIs? Cheers, Thilo _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical Skype: asangansiime Mobile: +2348028279250 http://asangansi.blogspot.com --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080225/f26f6c99/attachment.html>
