We're updating the issue view to help you get more done. 

Add an attribute to store the archetype_id in Locatable like described for archetype_node_id page 21 common.pdf

Description

Bert,

can you raise an issue on 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@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


Ocean Informatics Thomas Beale
Chief Technology Officer
+44 7792 403 613 Specification Program, openEHR
Honorary Research Fellow, UCL
Chartered IT Professional Fellow, BCS
Health IT blog View Thomas Beale's profile on LinkedIn

_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Environment

None

Status

Reporter

Bert Verhees

Labels

None

Components

Affects versions

RM Release 1.0.2

Priority

Minor