> The question to the implementors is: which name is preferable -
 > "node_id" or "archetype_node_id"?

I prefer "archetype_node_id" for the same reasons mentioned by Thomas. 
And I don't see any big problem caused by this change in our current 
implementation.

Rong

Thomas Beale wrote:
> 
> Dear all,
> 
> this CR has been processed, but since it involves probably the most 
> crucial piece of meta-data in the data - the archetype node ids which 
> are imprinted into their corresponding data nodes - I want to ensure 
> that we are doing the right thing, particularly by implementors. 
> (original CR text - 
> http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR-000024.txt)
> 
> To refresh your memories:
> 
>     * archetypes have an id for the whole archetype, like
>       "openehr-ehr-entry.blood_pressure.v1", and node-level ids
>       throughout the archetype, usually of the form "at0002" etc.
>     * these ids are included in data generated from archetypes. The node
>       ids are recorded in every node of the data; this is achieved by an
>       attribute in the LOCATABLE class (Common IM,
>       
> http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/common/im/REV_HIST.html
>       - note this version is the current release, without the CR-000024
>       changes)
>     * this attribute used to be named "meaning", and was of type DV_TEXT
>       (allowing it to be a DV_CODED_TEXT as well), but CR-000024
>       proposed to alter that to an attribute called "node_id" of type
>       String. The idea behind this change is that all you need in the
>       data is the archetype node_id to be able to match data nodes to
>       archetype nodes and process them. It also simplifies the XML
>       considerably. Further work has shown that a function called
>       "meaning" is useful - this function does retrieve the whole term
>       from the archetype, in the language of the locale. Doing this
>       means that the archetype must be available, and/or that in EHR
>       Extracts, at least a copy of the ontology section of the
>       archetype, where these terms are defined, is included.
> 
> This CR has passed, and the changes been made and tested in software but 
> not released. However, during ARB discussions it was suggested that the 
> attribute name in LOCATABLE be changed to "archetype_node_id" rather 
> than just "node_id". Remembering that this is the name of an attribute 
> in the _data_, the idea was that "archetype_node_id" makes it crystal 
> clear that the value is a node id from the archetype, not some other 
> node id being used in the data. In XML data, this one attribute, along 
> with the archetype_id attribute (the one that appears at archetype root 
> points in teh data) are the only two which will be expressed as XML 
> "attributes", i.e. appear inside the tag. This a) clearly separates 
> these special attributes from the "real" data attributes and b) 
> significantly facilitates XPath/XQuery processing (work so far suggests 
> that we will be able to have very powerful Xpath-based data querying in 
> openEHR systems that use XML).
> 
> The question to the implementors is: which name is preferable - 
> "node_id" or "archetype_node_id"?
> 
> My recommendation would be that, if it doesn't cause terrible problems 
> to current implementations, "archetype_node_id" is better - it really is 
> unambiguous, and doesn't get in the way if at some future time we want 
> some other attribute called "node_id" in the EHR information model. 
> However, I know that we have said in teh past, and documented as such, 
> the name "node_id". So - what do implementers/would-be implementers think?
> 
> - thomas beale
> 
> - If you have any questions about using this list, please send a message 
> to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Reply via email to