wiki:tickets/239

Outstanding CIM Issues

This page provides documentation for ticket:239

I originally setup this page b/c I didn't want to lose my train-of-thought while relocating to the US. It seems like a good idea, though. And I encourage others to use it. I will check it's contents regularly. [Allyn]

This ticket is now closed; all of these issues have been resolved and there are other specific tickets that exist for making changes to the CIM.


  1. There is no need to include the top-level schema (cim.xsd) in every other schema; modify the XSL accordingly. This has been implemented in changeset:389.
  2. There is an issue with experimental requirements that do not match up with software outputs; a requirement may be realised by transforming the output of a model. In that case, it seems overkill to try and capture the entire transformation process via metadata, instead Conformance could simply map the NumericalRequirment with the appropriate DataSources and then use a "description" attribute to describe how the requirement is actually realised. The CIM does support this.
  3. Similarly, there are NumericalRequirements that are not necessarily datasets - a requirement may be to use a particular scheme or to set a parameter to some particular value. Does the activity package need to change accordingly? I have raised this issue w/ the team and they insist that this is not required.
  4. Include sequencing info in the CIM. This has been captured in ticket:237.
  5. Finalise the ChangeProperty class. This has been captured in ticket:234.
  6. Bottom out the differences between software::NumericalProperties and software::ScientificProperties
  7. 'ClosedDateRange?' (extension of DataRange? in shared package) is empty, should be defined (Hans). The date/calendar classes have been re-organised and this is no longer an issue. [Allyn]
  8. Several tags (e.g. 'dataExtension' and 'dataDistribution' of type dataObject) should point to ISO standard types (Hans). This has been done for DataExtent? but DataDistribution? has been restructured so that it uses native datatypes [Allyn]
  9. Ideally the order of elements in the auto-generated XML schemas should match the order of appearance in the source UML model, rather than being sorted into alphabetical order as is currently the case. This is to ensure that properties (= XML elements) that naturally occur next to each other - like shortName and longName - do just that. This shouldn't matter if our XML documents were only ever read by computers, but I do not believe this will be the case in the first instance. (Phil)
    This has been implemented in changeset:510.(Allyn)
  10. The field 'CIM_Description/issueDescription' (quality.xsd / quality package) points to 'CIM_Description' again, what's the sense? That could lead to endless loops. (Hans) IssueDescription? has been changed to a string. [Allyn]
  11. The fields 'quality/scope/extent/Ex_Extent' (quality.xsd / quality package) and dataExtent (data.xsd / data package) aren't defined correctly. Should they point to the ISO type 'gmd:EX_Extent_Type' or an extra CIM extent type definition? (Hans) Yes, the classes in the quality package now use the ISO classes properly(er) [Allyn]
  12. There is still confusion between the distinction of NumericalProperties? and ScientificProperties?. These classes should therefore be consolidated into their parent class: ComponentProperties?.
    This has been implemented in changeset:534.
  13. The type definition / element 'dataset' (in activity.xsd) isn't defined! Or should this of a type 'dataObject'? (Hans) Changed to DataObject? [Allyn]
  14. In the shared packages (shared.xsd) there are some type definitions without a content: 'DataRange','Calendar','PropertyValue','DataSource'. (Hans)
    1. DataSource is purposefully empty; it is an abstract class just used to allow DataObjects and ComponentProperties to be used interchangeably in certain places. The others have been sorted out. (Allyn)
  15. Where do the CIM stereotypes get the unique documentID from (central server, other automatic generation, institutes separated like: MPI+123 / IPSL+123 /MET+123 / ...) ? (Hans)
  16. Who do I describe a data file with more than 1000 variables with the CIM dataObject? In dataObject I have only one topic with one unit. Should I do this with the childObject/parentObject link? (Hans). A DataObject? can have multiple DataContents?; it is up to you how you arrange the child/parent hierarchy.
  17. I would like to add the following attributes to the simulation class in the activity package:: Name: PreviousSimulation, Type: URI, Cardinality [0..1], Name: FollowingSimulation, Type: URI, Cardinality [0..*]. This is to capture the simple case of one simulation following on from the end of another. I think these attributes fit most appropriately in the Simulation Class because I want them to be available to both SimulationRun and SimulationComposite. (Charlotte) Done as of r2312 [Allyn].
  18. It would be very helpful for the local usage to move (or copy) the referenced external schemas into the CIM branch, So the references inside the XSD files to the external XSD files could move to:
 <xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="../external_schemas/gml/3.2.1/gml.xsd"/>
 <xs:import namespace="http://www.isotc211.org/2005/gmd" schemaLocation="../external_schemas/iso/19139/20070417/gmd/gmd.xsd"/>
 <xs:import namespace="http://www.w3.org/1999/xlink" schemaLocation="../external_schemas/xlink/1.0.0/xlinks.xsd"/>

I'm not sure what this snippet is meant to show - that is how the external schemas are currently referenced - however, I ought to be referencing them on remote schemas. This has been noted in ticket:881. [Allyn]

  1. I think it's not necessary to include all other XSD files of the CIM package inside every XSD file of the CIM package. (Hans) Sorry, Hans - this _is_ necessary b/c most schemas use elements from the others (especially the shared package). [Allyn]
  2. For the usage inside the GeoNetwork? I implemented inside the CIM schema a new type:
<!-- a CIMRecord can include any (single) <<document>> (ORG)-->
<xs:element name="CIMRecord2">
  <xs:complexType>
    <xs:choice>
      <xs:element ref="simulationRun"/>      
      <xs:element ref="simulationComposite"/>
      <xs:element ref="numericalExperiment"/>
      <xs:element ref="dataProcessing"/>
      <xs:element ref="ensemble"/>
      <xs:element ref="dataset"/>
      <xs:element ref="dataObject"/> 
      <xs:element ref="gridSpec"/>
      <xs:element ref="processorComponent"/>
      <xs:element ref="modelComponent"/>
      <xs:element ref="deployment"/>
    </xs:choice>
  </xs:complexType>
</xs:element>
<!-- a new CIMRecord can include any (single) <<document>> but could also be empty! (NEW)-->
<xs:complexType name="CIMRecord_Type">
  <xs:sequence>
    <xs:element ref="simulationRun" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="simulationComposite" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="numericalExperiment" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="dataProcessing" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="ensemble" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="dataset" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="dataObject" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="gridSpec" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="processorComponent" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="modelComponent" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="deployment" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>
<xs:element name="CIMRecord" type="CIMRecord_Type"/>

Sorry, it's a little bit unreadable but otherwise the wiki format will be 'damaged'. (Hans)

  1. Gerry noticed that the specialisations of DataStorage weren't showing up in DataObject. This was part of a larger issue: concim2appcim.xsl was not handling abstract classes properly. This has been fixed in changeset:601.
  2. Gerry noticed that both Activity::Simulation and Software::SoftwareComponent use the Deployment class. Is this intentional? Is there a difference between the two?
    1. Since Deployment is a <<document>>, and since the association from SoftwareComponent already used the <<reference>> stereotype, I went ahead and ensured that the association from Simulation did the same (changeset:603).
  3. Gerry noticed that if you added content to PropertyValues (ie: value attribute of ComponentProperty), it invalidated the XML. This has been fixed in changeset:602.
  4. What's with the type references output (--> TimeAverage) and outputDataset (-->instance of dataObject?) in the CIM stereotype 'simulation'? (Hans). TimeAverage is no longer part of a simulation [Allyn]