19115 1 Modularity Approach

As we developed the new XML schemas for ISO 19115-3 we used a new approach to improve modularity in the schema. This approach is used when a class in one namespace has an optional property from another namespace. As I am developing the schema implementation for ISO 19115-2 I need to use this approach in several locations. I am writing down the steps here so I get them right and can remember them!

Case 1: LE_Processing and SV_Parameter

We are adding a LE_ProcessParameter to the LE_Processing class so that parameters used in a LE_ProcessStep can be described. In order to do this we are reusing the concept of a SV_Parameter from the src namespace. This is an optional property in another namespace, time for modularity.

1. Move SV_Parameter to the common class namespace (mcc)

This namespace holds empty abstract types that are referenced by the namespaces that include the property in order to make it possible to import mcc (a small namespace with just abstract objects) instead of src (a big namespace with lots of stuff). the abstract object looks like:

<!-- Abstract SV_ServiceParameter added as part of ISO 19115-2 Revision 2017-01 -->
<element abstract="true" name="Abstract_Parameter" substitutionGroup="gco:AbstractObject"
  type="mcc:Abstract_Parameter_Type"/>
<complexType abstract="true" name="Abstract_Parameter_Type">
  <complexContent>
    <extension base="gco:AbstractObject_Type">
      <sequence/>
    </extension>
  </complexContent>
</complexType>
<complexType name="Abstract_Parameter_PropertyType">
  <sequence minOccurs="0">
    <element ref="mcc:Abstract_Parameter"/>
  </sequence>
  <attributeGroup ref="gco:ObjectReference"/>
  <attribute ref="gco:nilReason"/>
</complexType>

2. Adjust srv namespace

The substitution group for the SV_Parameter element needs to be changed to mcc:Abstract_Parameter_Type, i.e. from

<element name="SV_Parameter" substitutionGroup="gco:AbstractObject" type="srv:SV_Parameter_Type">
  <annotation>
    <documentation>parameter information</documentation>
  </annotation>
</element>
<complexType name="SV_Parameter_Type">
  <complexContent>
    <extension base="gco:AbstractObject_Type">
      <sequence>...
  </complexContent>
</complexType>

to

<element name="SV_Parameter" substitutionGroup="mcc:Abstract_Parameter" type="srv:SV_Parameter_Type">
  <annotation>
    <documentation>parameter information</documentation>
  </annotation>
</element>
<complexType name="SV_Parameter_Type">
  <complexContent>
    <extension base="mcc:Abstract_Parameter_Type">
      <sequence>...
  </complexContent>
</complexType>

At this point, the SV_Parameter at /mdb:MD_Metadata/mdb:identificationInfo/srv:SV_ServiceIdentification/srv:containsOperations/srv:SV_OperationMetadata/srv:parameter/srv:SV_Parameter is valid.

##3. Adjust the mrl namespace (i.e. lineageImagery.xsd) The new LE_ProcessParameter class is an extension of srv:SV_Parameter. This needs to be changed to eliminate the dependence between mrl and srv expressed as the import of the srv namespace into lineageImagery.xsd ()

The original looks like:

<element name="LE_ProcessParameter" substitutionGroup="gco:AbstractObject" type="mrl:LE_ProcessParameter_Type">
</element>
<complexType name="LE_ProcessParameter_Type">
  <complexContent>
    <extension base="srv:SV_Parameter_Type">
      <sequence>...</sequence>
    </extension>
  </complexContent>
</complexType>
'''
and

mrl:parameter mrl:LE_ProcessParameter srv:name/ srv:direction/ srv:optionality/ srv:repeatability/ mrl:valueType/ mrl:value/ mrl:resource mrl:LE_Source/ </mrl:resource> </mrl:LE_ProcessParameter> </mrl:parameter>

is valid XML