Does XMLSerializer (java) create archetype slots with too much extra information?
Hi Diego
This was the result of some overzealous efforts in the past (designed to
make XML look verbose :-). The discussion has been about the fact that
Occurrences does not need an includelower/upper and unbounded is not
necessary as it can never be a constraint statement.
The expression is new to me...
Sam
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Diego Bosc?
Sent: Wednesday, 4 January 2012 1:18 AM
To: For openEHR technical discussions
Subject: Does XMLSerializer (java) create archetype slots with too much
extra information?
This is a simple question: Why does a simple archetype slot like this
(ADL)
allow_archetype ELEMENT[at0001] occurrences matches {0..*} matches {
-- Archetype slot
include
archetype_id/value matches {/.*/}
}
ends up like this?
children xsi:type=ARCHETYPE_SLOT
rm_type_nameELEMENT/rm_type_name
occurrences
lower_includedtrue/lower_included
upper_includedfalse/upper_included
lower_unboundedfalse/lower_unbounded
upper_unboundedtrue/upper_unbounded
lower0/lower
/occurrences
node_idat0001/node_id
includes
tag /
string_expressionarchetype_id/value matches
{/.*/}/string_expression
expression xsi:type=EXPR_BINARY_OPERATOR
typeBOOLEAN/type
operator2007/operator
precedence_overriddenfalse/precedence_overridden
left_operand xsi:type=EXPR_LEAF
typeSTRING/type
item xsi:type=xsd:stringarchetype_id/value/item
reference_typeCONSTANT/reference_type
/left_operand
right_operand xsi:type=EXPR_LEAF
typeString/type
item xsi:type=C_STRING
pattern.*/pattern
/item
reference_typeCONSTANT/reference_type
/right_operand
/expression
/includes
I'm not complaining about the ultra-verbose occurrences (surely can be
improved, but there was already a discussion about this on this
mailing list).
I don't get the point of putting the 'expression' tags on this case.
It's like putting the same thing twice.
Is the 'operator' tag supposed to be understandable?
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Pablo, The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. If we reach a standard minimal program for openEHR courses ... From experiences with an another standard (HL7) based training courses I'd say it may be hard to reach consensus as to what the minimum should be - there is a fair amount of difference between various countries, as well as how one structures a (set of) training courses [e.g. 1 long one, an introductory and an advanced], and the target audience [e.g. clinical, hardcore programmers without any clinical knowledge]. In general the most useful thing for all concerned is probably for the standards organization to make a statement like we know that trainer X provides good quality training courses [this aids the trainer in selling the training course, it aids the prospective attendee as a statement of quality, and it aids the standardization body because it has a known list of educators it can refer to]. Determining who provides a good quality training course may not always be that easy to quantify, but in these relatively small standardization communities (whether openEHR, HL7, DICOM, IHE, etcetera) the nomination for approval can be backed up / seconded (or the reverse: thumbed down) by other known active volunteers. TTYL, -Rene -- Rene Spronk Cell: +31 (0)655 363 446 Senior ConsultantFax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholmskype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 Ringholm bv - Making Standards Work - Courses and consulting
Outcomes conclusions of the openEHR course in spanish ( ideas for the future)
Hi Pablo, and all I perfectly agree your idea. I have thought as you mentioned. I am planning my tool-chains on my Ruby implementation, too. Certification criteria are very difficult to evaluate. Training course would be a homework to localize. Shinji Kobayashi 2012/1/4 pablo pazos pazospablo at hotmail.com: Hi everyone, Recently we have ended the first edition of the course with a huge success. And now we are thinking about the next steps to take. Here is a post on my blog about the conclusions and future actions:?http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html (yo can see it in english by clicking ENGLISH on the top right corner of the blog). I want to share with the community a couple of ideas mentioned there. It would be very nice to know what you think. openEHR certification: The first idea is on standarizing openEHR training, and to think about an openEHR certification. I think this could be very good for the community and for the openEHR organization too. It could be possible to create a mail list for openEHR trainers (openehr-trainers at openehr.org)? So we could discuss about the topics and ways of evaluation, and come out with an standard minimal program to all openEHR courses. If we reach a standard minimal program for openEHR courses, could we get formal support from openEHR.org to issue internationally valid openEHR certificates? (obviously this is a question for the future, but IMO we need to start thinking about it now). 10 projects to adopt openEHR: We thought about 10 projects (or so) in two areas: software and clinical modeling. Because openEHR propose a tool-chain based process of creating EHRs, we need to have each one of the links of that chain in order to adopt and implement openEHR easily. Now there is a little tooling available, and some of it is not open source. In projects at a national level we need to use open source software, because each country will need to make it's own customizations to each tool. In the other hand, we need to model other things that are clinical knowledge too, like processes and rules to enable CDS, in order to support full EHR implementation (e.g. I think we could recommend ways to express rules based on archetype ids and paths, and create software tools to support that specification, but we need to work the openEHR services specs first). There is a diagram on my blog post that shows the tools we propose to 1. develope if there is no tool that support its functionality or it's closed-source, 2. improve the current open source tools. On the clinical modeling side, we have engaged doctors and nurses on the creation and translation of archetypes. Now there are two of our students that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr. Leonardo Der Jachadurian. I hope we could propose to create prototypes of those projects in out local universities and coordinate the projects so we do not overlap each other, with the objective of completing the tool chain with open source developments. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
Reference Model based application development - RIMBAA March 8 in Gothenburg
The location and date of the Reference Model based implementers meeting (HL7 RIMBAA) have been confirmed: ** March 8, 2012, RIMBAA, in Gothenburg, Sweden Core topic: software implementation aspects of Refence Model based applications, focusing on both the 13606/OpenEHR RM as well as the HL7 RIM. Sweden has opted to use 13606/OpenEHR as the base standards for its national infrastructure, which means there should be lots of opportunities to discuss RM based implementation issues at this venue. Draft agenda: http://wiki.hl7.org/index.php?title=RIMBAA_201203_Agenda Please register at the bottom of that wiki page should you plan to attend, or send me an e-mail. This e-mail just serves to announce the data and location (thanks to Mikael Wintell, VG Region, for sponsoring the venue) - I'll get back to this list to announce a more detailed agenda, and to request speakers from amongst the Swedish [and other European countries] 13606/OpenEHR implementer community to speak to the 'implementation lessons learned' and the 'architectural approaches chosen'. With best regards, -Rene -- Rene Spronk Cell: +31 (0)655 363 446 Senior ConsultantFax: +31 (0)318 548 090 Ringholm bv The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.com twitter:@Ringholmskype:rene_ringholm Ringholm is registered at the Amsterdam KvK reg.# 30155695 Ringholm bv - Making Standards Work - Courses and consulting
Did anybody implement AQL with a LL parser framework?
Greetings, The AQL grammar from the wiki has direct and indirect left recursion. Which means without changes in the grammar, LL parser generators (both JavaCC and Anltr) can't generate parsers for this grammar. I'm curious if anybody has refactored this grammar for LL parser generators. Shinji? Your latest release includes an AQL parser does not it? Could you please share your method? I can always look at the code, but you'd probably save me time :) I'm interested in experiences of others too. Kind regards Seref -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120104/e9263f32/attachment.html
Did anybody implement AQL with a LL parser framework?
So has AQL been selected as the official openEHR query language? 2012/1/4 Seref Arikan serefarikan at kurumsalteknoloji.com: Greetings, The AQL grammar from the wiki has direct and indirect left recursion. Which means without changes in the grammar, LL parser generators (both JavaCC and Anltr) can't generate parsers for this grammar. I'm curious if anybody has refactored this grammar for LL parser generators. Shinji? Your latest release includes an AQL parser does not it? Could you please share your method? I can always look at the code, but you'd probably save me time :) I'm interested in experiences of others too. Kind regards Seref ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Did anybody implement AQL with a LL parser framework?
On 04/01/2012 15:37, Seref Arikan wrote: Greetings, The AQL grammar from the wiki has direct and indirect left recursion. Which means without changes in the grammar, LL parser generators (both JavaCC and Anltr) can't generate parsers for this grammar. I'm curious if anybody has refactored this grammar for LL parser generators. Shinji? Your latest release includes an AQL parser does not it? Could you please share your method? I can always look at the code, but you'd probably save me time :) I'm interested in experiences of others too. there is no guarantee that the current grammar is the best one, and in my view, a better grammar could be developed. We just need to make sure it deals with the typical queries we write, and ones that are already written (or at least that the latter could safely be translated). Other thing to keep in mind: many non-LL grammars are probably computable as LL grammars with sufficient tokens of lookahead. - thomas
Did anybody implement AQL with a LL parser framework?
On 04/01/2012 15:54, Diego Bosc? wrote: So has AQL been selected as the official openEHR query language? not officially. It has been implemented in at least 2 production systems (it may be 3), so we know it 'works'. But at least from my point of view, and I am sure the primary developers (Chunlan Ma, Heath Frankel) would agree - it can only benefit from wider inspection and testing by the community. I would suggest that the current AQL spec can be considered to be in a 'trial' state now. There is also a very good piece of work called a-path which Zilics did in Brazil a few years ago, and I think that should be integrated into ADL 1.5 (rules section) and probably also AQL. There are others thinking about an expanded AQL, with the equivalent of schema definition operations of SQL as well. Once the current specification governance has been clarified, I suggest that the current AQL spec be declared 'trial' just so we have something solid to work with, and then a Query project group be set up to consolidate work on a next generation AQL. - thomas
