Thanks for agreeing so much, the future looks great ;-) Bert
On 24-06-12 20:30, Thomas Beale wrote: > 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 > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/1cdf1be0/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 19394 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120624/1cdf1be0/attachment-0001.png>
