Hi! I also think that shorter more readable paths are preferable for query strings, but maybe software should be required to accept both. The semantics for default path resolution algorithm might be good to put in the specs however we do to reduce the risk of misinterpretation.
A possibly stupid question regarding some of the points below: Aren't there cases when software using different human language translations of archetyped EHR content becomes easier to write if the at-codes are stored in the all LOCATABLE nodes of EHR data. (That way a simple at-lookup to the "ontology"-part will give you a label in the preferred language.) Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Wed, Oct 1, 2008 at 21:08, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > I should be clear here for everyone's benefit - such paths are guaranteed > mathematically to be equivalent. Things to be resolved are: > > 1. whether we use at-codes on nodes where they add no semantic value > and are not needed for dis-ambiguation > 2. regardless of which way we go on 1., whether we use 'simplified' > paths (only have at-codes where needed) for querying > 3. what we do in the AOM spec, which says that all C_OBJECTs have a > node_id; this clearly is not necessary 100% of the time, and there are > easily statable rules for when they are needed (which you will see in the > ADL 1.5 draft I will put up in the next day or so). > 4. how we populate the LOCATABLE.archetype_node_id field in data, for > archetype object nodes that have no at-code. > > I am personally in favour of the minimal approach - it makes paths shorter > and more readable. I know the guys in Valencia have gone the other way. I > can see reasons for this in the past when the specificatoins were not strong > enough, but the new set of specificatoins will take care of many points of > validity not previously defined. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081002/e9e9ca15/attachment.html>
