OK Bert
On 09/27/2013 05:20 PM, Thomas Beale wrote: > > Bert, > > can you raise an issue on SPECPR > <http://www.openehr.org/issues/browse/SPECPR> - that's the issue > tracker that we use to feed specification work. If you just paste most > of this post in as the description that will be enough to get back to > this when more people can get involved (which will be fairly soon). > > thanks > > - thomas > > On 26/09/2013 11:21, Bert Verhees wrote: >> >>>> >>>> In my system it is not useful to preload archetypes, because, >>>> archetypes are only parsed once in my system. >>>> That is when they are saved in the system. They are parsed in order >>>> to create a RNG/Schematron definition. >>> >>> ok, so the downstream form of an archetype you are using is a >>> Schematron schema - so that's the thing that needs to be stored. >> >> OK, I misunderstood that part of the discussion, having a form of >> XML-schema is a representation of an archetype, which can be for >> specific purposes like validation more efficient then the >> archetype-object, depending on the technical architecture of the kernel. >> >> It seems that we agree on that. >> >>> >>>> >>>> That is used to validate the data, and if new data are entered, >>>> then they will be checked against that RNG/Schematron definition, >>>> not against the parsed archetype. >>>> The schema is loaded in microseconds and the validation takes one >>>> second. >>>> >>>> After the data are validated, they are stored in an XML-database, >>>> and they will never be validated again. They are ready for >>>> XPath-queries and XQueries, and all kind of complicated handling >>>> without even looking at an archetype. >>> >>> right - that sounds like all other archetype-based systems I know of. >>> >>>> >>>> So the refusal to specify a "archetype_id" in the specs is, in my >>>> architecture, bad for performance, because it forces extra >>>> archetype-parsing, so I have that property without the consensus >>>> with the specs, and I do not see it as a waste. I make sure that >>>> when I have to export data to an OpenEHR system, I will put the >>>> archetype_id in the archetype_node_id property. >>> >>> but the specs already specify archetype_details, which contains the >>> archetype id. And you can detect that easily in a schematron schema >>> I guess. So you can easily figure out that you are on one of those >>> nodes. Is the real problem simply that the syntax of what is in >>> archetype_node_id on one of those nodes - an archetype_id rather >>> than an at-code - causes some problem in your processing? I am not >>> clear on what though... are you trying to use the at-code texts at >>> runtime? Are they also in the Schematron schema? >> >> We are not talking about the OpenEHR reference model, but about >> archetyped data-handling. >> >> I have two arguments, the first one is most simple to explain, so I >> start with that. >> ---------------------- >> 1) >> *A golden rule in design is that attribute-names should indicate what >> they are there for.* >> >> We are not writing obfuscated code, but readable code, because the >> cold war is finished, and we do not need to confuse the Russians >> anymore, so we can safely honor this rule. >> >> This means, an attribute (in the ADL common notation) which contains >> the archetypeNodeID should be called archetype_node_id and an >> attribute containing an archetypeId should be called archetype_id and >> it is confusing to use the attribute archetype_node_id to store both, >> and even, which makes it worse, without indication about what is in it. >> ---------------------- >> 2) >> The second argument is a more technical issue and a bit difficult to >> explain, but I try with an example: >> >> Imagine you have extracted an XML-path in your datastorage which says >> ....../details[@archetype_node_id="at0001"]/items[@archetype_node_id="at0003"]/......... >> >> >> >> Say, your client software wants to build a GUI, and uses the >> ontology-information to create the GUI-control-indicators and >> help-information. I think this is possible to do that that way. It >> makes dynamic GUI-building possible. >> This example-path above is easy to find and will not cause any >> complicated handling. >> >> But in the current situation, the path can look like: >> ....../details[@archetype_node_id="at0001"]/items[@archetype_node_id="openEHR-EHR-ITEM_LIST.address.v1"]/......... >> >> >> >> First Step: Now the GUI software wants to have a container-control >> which contains the items, and it looks in the ontology of the >> containing data-set-archetype to find the archetype_node_id: >> "openEHR-EHR-ITEM_LIST.address.v1" >> >> It does not find it, because it is not there. >> >> Second Step: Now you suggest that the software should look if there >> is an archetypeDetails attribute, to see if there is another >> archetype to be used for ontology search. This is one step extra the >> software needs to do. >> >> Should it do this at every archetypeNodeId, or only if search did not >> give a result? That is a statistical question, which workaround will >> be applied more and cost more on the long term. Maybe some tricks may >> help, and we get tricky software. >> >> Third Step: Then, the archetype_node_id in that archetype to search >> for is invisible for the software, because, it is not in the path. >> So, this step is a more complicated, the software needs to know which >> archetype_node_id belongs to the root of that archetype, and then it >> can find in the ontology section what the description is. >> >> This all could be so much easier, and efficient when the extracted >> path looked like: >> ....../details[@archetype_node_id="at0001"]/items[@archetype_id="openEHR-EHR-ITEM_LIST.address.v1" >> >> @archetype_node_id="at0000"]/......... >> >> The software would know in one step what to do to build its dynamic >> GUI. It would see in one step that there is another >> archetype/ontology-section involved, and it would know in the same >> step which archetypeNodeId to look for. >> >> It seems to me that the golden rule in my first argument is there for >> good reason. It makes code not only better readable, but also more >> efficient, it forces short code-paths to solutions for >> information-handling >> ---------------------- >> >> I hope my arguments are clear now. >> >> Bert >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> > > > -- > Ocean Informatics <http://www.oceaninformatics.com/> *Thomas Beale > Chief Technology Officer* > +44 7792 403 613 Specification Program, /open/EHR > <http://www.openehr.org/> > Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> > Health IT blog <http://wolandscat.net/category/health-informatics/> > View Thomas Beale's profile on LinkedIn > <http://uk.linkedin.com/in/thomasbeale> > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130927/018c07b8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130927/018c07b8/attachment.jpe> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130927/018c07b8/attachment.png>
