>> >> 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
