Various changes are required to the EHR Extract to be properly compliant to the Release 1.0 reference model, as follows.
An extract form of the RM class VERSIONED_OBJECT is needed in the extract, corresponding to the changed definitions of the classes VERSIONED_OBJECT and VERSION in the RM. The X_ variants are data-oriented classes.
There are two requirements for Folders in Extracts. The first is that the Extract may be required to faithfully carry the Folder structure from an openEHR system (including its previous versions - just as for Compositions) elsewhere. The other is that users might want to create Folders local to the Extract itself (e.g. for the parts of a Discharge summary). Only the second of these requirements is currently addressed.
As indicated in SPECRM-6, there are many breaking changes. Although I accept most of the changes, we need to consider the backward compatibility of these changes. Perhaps this should not be 1.0.3 change unless there is some backward compatibility.
I am not sure about the need for EXTRACT_ITEM to inherit from LOCATABLE. The need to specify a name on each item is cumbersome.
Why does EXTRACT_CONTENT_ITEM.item exist when this is redefined in the subtypes? This is not supported in most languages.
re: EXTRACT_ITEM inheriting from LOCATABLE, the 'name' field doesn't need to be specified anywhere, it just needs to be set in the normal way at runtime. The default value is always just the 'text' value of the at-code/id-code for that node. In this case, multiple runtime nodes will usually just get the same name. I think we probably did this so that the EXTRACT_FOLDERs are LOCATABLE. A better approach could be just to make LOCATABLE inherit into EXTRACT_FOLDER - thoughts?
re: EXTRACT_CONTENT_ITEM.item, that just signals that EXTRACT_CONTENT_ITEM must have an item of some kind, and that's where the main data are. As far as I can see, this is supported in Java 1.5 and later. C# seems to do some convariant redefinition. But even if some languages don't implement it, all they have to do is not define EXTRACT_CONTENT_ITEM.item - only define 'item' in subtypes. I think it's worth keeping it in the spec because it shows the design intent more clearly than if it is not there.
I'll accept these changes