On 25/09/2013 23:20, Bert Verhees wrote: > 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.
exactly - that's why you should pre-load them - I don't mean cache them in memory - I mean compile the them once, compile the templates, generate the operational templates, and store all of these in a local database or location in a post-parsed form, typically an XML or other object (e.g. JSON) object serialisation. If your system encounters a new archetype, that needs to be compiled and saved in the same way as well. > > 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. > > 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? > > Thanks for the discussion, sorry that we could not find an agreement. well, I'm just trying to understand the problem. There will certainly be a more scientific discussion in the near future with the specifications editorial committee. But it needs clear evidence of problems if it is going to change any specifications. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130926/89999169/attachment-0001.html>
