On 24/06/2012 13:21, Bert Verhees wrote: > Thanks, David for your answer. > > Excuse me my bit confusing email from yestrday, I was in a hurry > preparing a meal for guests, and at the same time working. > > This not about bugs but mostly about features as designed > > Although there are formal reasons for the current status of the > archetype-editors, is the situation not very satisfying for > customers/users, and does not help to get customers to choose for the > OpenEHR architecture. > Silently losing parts of archetypes, having to work with text-editors, > unpredictable behaviour. > > - The LinkEHR-editor does not accept OCEAN-editor constructs as > C_DV_QUANTITY, and thus, does not allow multiple constraints on a > DV_QUANTITY > - The Ocean-editor silently removes the DV_QUANTITY construct created > by the LINKEHR-editor, and asks the the user to save the changes. If > the user has made some changes and wants to change them, and he is > unaware of the problem, he removes without knowing his DV_QUANTITY > constructs, which are legal constructs. > - The OCEAN editor silently removes the NodeID on DataValues which are > always created by the LinkEHR editor. > - The LinkEHR editor silently adds NodeID's on DataValues as the > archetype does not have them. > > /The problem with the NodeId on ELEMENT-values is more serious than it > appears, because software can use the path to the ELEMENT-value > instead of the path to the ELEMENT itself. > After opening and saving the archetype in the OCEAN-editor, the > node-id's are gone, and this can render software to become useless, > because the paths the software used are not anymore visible. > The recreating of the NodeID's is not a solution because there is no > guarantee the node's will get the same at-codes. > /
Normally, there is only 1 child of an ELEMENT, and an ELEMENT always has a node_id (due to the rule for multiple-valued attributes, i.e. CLUSTER.items); that means in these cases, the path for the ELEMENT and the path to the data value it contains are distinct, as you can see here: In the rare cases where there are multiple alternatives for ELEMENT.value, the node_id might not be there, according to the current rules in the ADL 1.5 draft, if the RM types are different. This probably will lead to ambiguity, so I think the current rules have to be tightened to force all single-attribute children to have node ids in all cases. With that change, the rules still allow for no node_id where it is not needed to disambiguate sibling nodes in archetypes, which is very frequently (nearly all ELEMENT.value) cases, and quite a few other attributes as well. The idea is to avoid having to create junk node ids and unnecessarily long paths. > // > - The LinkEHR creates per default the line: terminologies_available = > <...> which is not accepted by the Ocean-Editor All tools should silently ignore this line in the future, and when serialising, not generate it, unless in a strict 1.4 mode. > - The OCEAN editor still not is able to create Demographic archetypes, > the LINKEHR editor does. > we will be able to do that with the ADL Workbench soon. > Solutions could be: > - Let the LinkEHR editor accept C_DV_QUANTITY and C_DV_ORDINAL as the > Ocean editor does > - Let the Ocean editor accept DV_QUANTITY constructs. it certainly should do that... > - Never change archetypes silently!!! I agree that this behaviour is not preferable... > - Make the creation of NodeID's on datavalues in the LinkEHR editor > optional (configurable and put it default off, as it is only for > transition-purpose which isn't possible in the free version) Right; we should make all tools obey the new rules, i.e. if there are sibling nodes, then you need node ids, otherwise they are optional. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/10c3ca17/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ffejcbde.png Type: image/png Size: 19394 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/10c3ca17/attachment-0001.png>
