Fwd: Re: xml archetypes to xforms
--- Ime Asangansi asangansi at yahoo.com wrote: Date: Wed, 9 Apr 2008 10:51:50 -0700 (PDT) From: Ime Asangansi asangansi at yahoo.com Subject: Re: xml archetypes to xforms To: adam.flinton at nhs.net Hi Adams, Please find my comments below: I have the XForms Engine up on the OHT site but they're waiting to go public (I have no real idea what the delay is but)...hopefully anonymous access is an any day now event. https://xmlprocess.projects.openhealthtools.org/ I have since downloaded but I had errors when I tried to run. I have sent you the tomcat log for your very kind scrutiny This drill down is what is a bit of a pain at the moment were one to wish to open a template then see a generated XForm GUI... This would be the ultimate IMHO C) Wrt moving existing forms etc into Archetypes/templates etc what I've been playing with is OpenOffice as it's forms designer is XForms based allows one to create a model/instance based form in a WYSIWYG way with all the niceties XForms offers wrt data analysis/mapping e.g. types from both std XSD your own schemas/simple types (e.g. restricting a length or applying a pattern). You can then map that model to the relevant templates/archetypes while allowing the users to be sure that you've captured all the fields that their current form captures. In a very neat move you can even exports that form as an Adobe pdf form. cool... uh.. D) What has raised itself as I've been playing with concepts to do with this is that you should be able to create a form at the lowest possible level then accrete them into a whole i.e. a template/archetype should have it's own xform This is really interesting to hear (in the absence of a template specification, Adam. Here you are kind of talking about archetype xforms. I am really wondering how you convert those constraints stuff in the definition part of the archetype into some cool xforms stuff. Adam, I didnt contribute to the archetype specs neither do I fully understand it... but I kinda think this is the core issue which is locatable e.g. archFileName_xform.xhtml which then includes...etc. i.e. if I open a template xform the xform contains other templates/archetypes etc it would be nice to simply load them via linking (e.g. xlink or similar) rather than some sort of involved drill down render approach. i.e. for a given archetype/template, the XForm is just for that archetype/tamplate then includes the relevant form for the relevant child archetype/template etc. an example is that you might have an AE admissions form with a select1 tick box a set of choices e.g. has: head wound chest wound leg wound if you click head wound you would want to see the head wound form. e.g. http://internet-apps.blogspot.com/2006/08/using-subforms-in-xforms.html It is possible that the operational template as per: - the XML templates should probably become .xts (ts = template specification), because there will also be an operational template file, which is a template with all substitutions done, with an extension like .xot (ot = operational template) or .xtom (tom = template object model). The current 'templates' are template 'specifications', i.e. a set of differences with respect to archetypes. The 'operational' form is what can be used to create message definitions from, and can be used at runtime. cool Thanks, Adam, for this Cheers, Ime __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
xml archetypes to xforms
Hi Adams et al, Nice to hear that. But I think the tough issue is converting the archetypes xml to xforms. Please how do you do that? especially converting the definition section... Just to add this: we are shifting from Infopath... It has never been a nice thing to be locked into that. Thats why, Adam, it would be interesting to see you guys put this OSS too. You said (some time ago) that you were waiting for the OHT. Please how is that going now? Thanks Cheers, Ime Adam Flinton adam.flinton at nhs.net wrote: Ime Asangansi wrote: 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 We have built a generic XForms engines which uses Chiba to render the XForm into XHTML + Ajax etc. Adam ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical - Looking for last minute shopping deals? Find them fast with Yahoo! Search. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080320/1eefc36c/attachment.html
xml archetypes to xforms
Ime Asangansi wrote: Hi Adams et al, Nice to hear that. But I think the tough issue is converting the archetypes xml to xforms. Please how do you do that? especially converting the definition section... there are already answers to this, but you don't want to convert archetypes to Xforms, you want to convert openEHR Templates. The new specifications for templates are underway and drafts will be available in the next few weeks. - thomas beale
xml archetypes to xforms
Hmm... yes, thanks for that correction looking forward to that... Ime --- Thomas Beale thomas.beale at oceaninformatics.com wrote: Ime Asangansi wrote: Hi Adams et al, Nice to hear that. But I think the tough issue is converting the archetypes xml to xforms. Please how do you do that? especially converting the definition section... there are already answers to this, but you don't want to convert archetypes to Xforms, you want to convert openEHR Templates. The new specifications for templates are underway and drafts will be available in the next few weeks. - thomas beale ___ 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 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
xml archetypes to xforms
Ime Asangansi wrote: 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 We have built a generic XForms engines which uses Chiba to render the XForm into XHTML + Ajax etc. Adam ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail **
xml archetypes to xforms
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
xml archetypes to xforms
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
xml archetypes to xforms
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
xml archetypes to xforms
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 Thilo Schuler thilo.schuler at gmail.com wrote: Hi Ime and others XForms is an intriguing technology and IMHO (and others' !) it seems very suited to generate forms from templates and their underlying archetypes . I will first point you to two recent sources where XForms where mentioned within the openEHR community: 1. Wiki (look in the comments area): http://www.openehr.org/wiki/display/dev/User+Interface+and+openEHR+data 2. Mailing list thread: http://www.openehr.org/mailarchives/openehr-technical/msg03208.html So there are several people that have thought about or have actually implemented code regarding XForms openEHR archetypes. I will try to list the relevant people that I know of: 1. Carl Alfon from Link?ping University (Sweden) currently writes a thesis on Archetype based EHR GUI. In his practical work he generates XForms using the openEHR ADL parser plus custom code. 2. Adam Flinton from the NHS has an complete Xml forms engine which can be used with (besides others) XForms (Chiba to render into Ajax-ified html). He also offered that this could be open-sourced. 3. Lisa Thurston from Ocean Informatics wrote a set of customizable/extendable XSLT scripts that creates a generic read-only view of openEHR instance data. 4. Heath Frankel (programming lead at Ocean Informatics) and I have thought about using the Template Data Schemas (TDS) that can be generated from templates (using the template designer) as the basis for the XForms model. Tests are needed whether the currenty availble XForms engine implementations support such complex nested schemas... 5. Myself, I have the humble goal (because I have so little time) of writing a XForms GUI for a small template with only a couple of archetypes that connects directly to an IBM DB2 server via web services. Will start with a static one but finally generating it would be awesome... A first test with a trivial 4 field form was successful in retrieving and uploading data from the DB2 server. 6. There are a couple of more ppl generally interested in openEHR GUIs: Helma van der Linden (University of Maastricht), Erik Sundval (University of Link?ping) and Sam Heard Hugh Leslie from Ocean Informatics. I think we should join forces and create a sub-project to share ideas and maybe code for an openEHR XForms Toolkit. I have proposed this in December already but have been slack busy. What is everybody's opinion (especially the people listed) on such a project? Regarding GUI generation in general Hugh has argued that it won't necessarily will be the most usable forms. I think that this is true (and for complex data entry in complicated clinical workflows it will propably never change) and in that case the generated GUI would be a good start to for further hand-coded customization (scaffolding GUI code). However one day we might be surprised by the power of XForms especially once the engines have become even better and special openEHR widget extensions are available (see again http://lib.tkk.fi/Diss/2007/isbn9789512285662/isbn9789512285662.pdf). Will be on a long anticipated and much needed skiing holiday for the next 7 days, so won' t be able to reply until I return. Cheers, Thilo PS: See one more remark inline. On Feb 9, 2008 4:50 PM, Ime Asangansi wrote: Hi everybody, I am working on a project that might involve generating xforms from archetypes. While there are many possibilities in doing this (including an internal form schema designer within the OpenMRS that is infopath-based), before making design decisions, I would really like to learn from people who are using archetypes to drive Xforms generation for their app. And how is the seemingly complex archetype 'definition' part handled? Also I would really like to know how the interface in the Ocean/LiU editors are generated? XSLT or ...? No XSLT but going recursively through the object model in the kernel component to create a certain widget for every datatype at the leaf nodes. But others know better. Thirdly, has or is any one working on translating openehr archetype based messages to HL7 v2? I might need to translate (or transform) Xml data to HL7. Thanks, in anticipation. rgds, Ime Never miss a thing. Make Yahoo your homepage. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org
xml archetypes to xforms
Hi Ime and others XForms is an intriguing technology and IMHO (and others' !) it seems very suited to generate forms from templates and their underlying archetypes . I will first point you to two recent sources where XForms where mentioned within the openEHR community: 1. Wiki (look in the comments area): http://www.openehr.org/wiki/display/dev/User+Interface+and+openEHR+data 2. Mailing list thread: http://www.openehr.org/mailarchives/openehr-technical/msg03208.html So there are several people that have thought about or have actually implemented code regarding XForms openEHR archetypes. I will try to list the relevant people that I know of: 1. Carl Alfon from Link?ping University (Sweden) currently writes a thesis on Archetype based EHR GUI. In his practical work he generates XForms using the openEHR ADL parser plus custom code. 2. Adam Flinton from the NHS has an complete Xml forms engine which can be used with (besides others) XForms (Chiba to render into Ajax-ified html). He also offered that this could be open-sourced. 3. Lisa Thurston from Ocean Informatics wrote a set of customizable/extendable XSLT scripts that creates a generic read-only view of openEHR instance data. 4. Heath Frankel (programming lead at Ocean Informatics) and I have thought about using the Template Data Schemas (TDS) that can be generated from templates (using the template designer) as the basis for the XForms model. Tests are needed whether the currenty availble XForms engine implementations support such complex nested schemas... 5. Myself, I have the humble goal (because I have so little time) of writing a XForms GUI for a small template with only a couple of archetypes that connects directly to an IBM DB2 server via web services. Will start with a static one but finally generating it would be awesome... A first test with a trivial 4 field form was successful in retrieving and uploading data from the DB2 server. 6. There are a couple of more ppl generally interested in openEHR GUIs: Helma van der Linden (University of Maastricht), Erik Sundval (University of Link?ping) and Sam Heard Hugh Leslie from Ocean Informatics. I think we should join forces and create a sub-project to share ideas and maybe code for an openEHR XForms Toolkit. I have proposed this in December already but have been slack busy. What is everybody's opinion (especially the people listed) on such a project? Regarding GUI generation in general Hugh has argued that it won't necessarily will be the most usable forms. I think that this is true (and for complex data entry in complicated clinical workflows it will propably never change) and in that case the generated GUI would be a good start to for further hand-coded customization (scaffolding GUI code). However one day we might be surprised by the power of XForms especially once the engines have become even better and special openEHR widget extensions are available (see again http://lib.tkk.fi/Diss/2007/isbn9789512285662/isbn9789512285662.pdf). Will be on a long anticipated and much needed skiing holiday for the next 7 days, so won' t be able to reply until I return. Cheers, Thilo PS: See one more remark inline. On Feb 9, 2008 4:50 PM, Ime Asangansi asangansi at yahoo.com wrote: Hi everybody, I am working on a project that might involve generating xforms from archetypes. While there are many possibilities in doing this (including an internal form schema designer within the OpenMRS that is infopath-based), before making design decisions, I would really like to learn from people who are using archetypes to drive Xforms generation for their app. And how is the seemingly complex archetype 'definition' part handled? Also I would really like to know how the interface in the Ocean/LiU editors are generated? XSLT or ...? No XSLT but going recursively through the object model in the kernel component to create a certain widget for every datatype at the leaf nodes. But others know better. Thirdly, has or is any one working on translating openehr archetype based messages to HL7 v2? I might need to translate (or transform) Xml data to HL7. Thanks, in anticipation. rgds, Ime Never miss a thing. Make Yahoo your homepage. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
