Op 25-9-2013 22:47, Thomas Beale schreef: > On 25/09/2013 00:53, Bert Verhees wrote: >> >>> sure - if you have a separate property to store the archetype id, it >>> is empty in 95% of all object instances, and also you need a class >>> invariant to prevent it being filled at the same time as the >>> archetype_node_id (at-code) property. >> >> I must disagree, it is very common in archetypes, I think it is in >> 90% of the archetypes that the root of a definition also has a node_id. > > It's 100% ;-) > > But what i meant was that in any instance structure, say a > Composition, most of the nodes in the data tree will have an at-code > in archetype_node_id, only a few - the archetype root points - will > have archetype ids. > > The at-node corresponding to the root point is just the at0000 code > (or a specialised version of that). Putting that in the data is not > much use.
People could use it for some ontology-message. I don't understand why it is there when it is not allowed to use, or when it is not possible to retrieve the connected information. Again this is some small thing in the specs which has no purpose while people could expect it. This is caused in chain reaction by the other, I think, ambiguous spec. Because the other spec makes it impossible to query the atcode from the definition of an archetype. I must say that this is not very nice defined. -------------------------- skip skip ------------------------------------------------------ > but the Xpath engine doesn't need to do this. It just processes the > query paths it finds in the queries. It doesn't need to know what > archetypes were used to structure it. Not quite so, XPath can have properties as path-arguments, and it must possible to query for certain objects with a specific archetype_id and another specific node_id. Since the root of the definition is allowed to have an node_id, one can expect people use it, so there can be a need to query them. As I said before, as a builder/designer of a two level modeling system, you cannot predict which archetypes people use. And you must be sure that the archetypes they use, can be used safely, which is not always the case in the current specs, because there may be possible information which cannot be reached at query-time. > > -------------------------- skip skip > ------------------------------------------------------ > > > My suspicion from what you are saying is that you are not doing a > pre-load of operational templates into your back-end system. If you > had that, the query service can work very optimally. It depends if it is wished to have archetypes pre-loaded. If you run a kernel as a public service, and there are hundreds of archetypes operational, then it will cost a lot of memory to pre-load them all. The parsing an archetype should not be done more then once in its lifetime, it is expensive and unnecessary computing, especially when the archetypes are large. Saving them preloaded is a real memory-eater. 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. 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. 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. Thanks for the discussion, sorry that we could not find an agreement. regards Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130926/f2bcfd23/attachment.html>
