Re-organize XSDs and support documentation

[amilan17]

Publish version 2021-2 RC to https://schemas.wmo.int/iwxxm using the following structure.

• iwxxm/
  • 1.0/
  • ...
  • 3.0.0/
  • 2021-2RC2/
    • examples/
    • html/
    • iwxxm.xsd
    • releaseNotes.txt
    • rule/
  • airmet/
    • 3.1.0/
      • airmet.xsd
  • common/
    • 3.X.X(?)
      • common.xsd
  • gmliwxxm/
    • 3.X.X(?)
      • gmliwxxm.xsd
  • iwxxm-collect/
    • 3.X.X(?)
      • iwxxm-collect.xsd
  • measures/
    • 3.X.X(?)
      • measures.xsd
  • metarspeci/
    • 3.1.0
      • metarspeci.xsd
  • metFeature/
    • 3.X.X(?)
      • metFeature.xsd
  • sigmet/
    • 4.0.0/
      • sigmet.xsd
  • spaceWxAdvisory/
    • 3.0.1/
      • spaceWxAdvisory.xsd
  • taf/
    • 3.0.1/
      • taf.xsd
  • tropicalCycloneAdvisory/
    • 3.1.0/
      • tropicalCycloneAdvisory.xsd
  • volcanicAshAdvisory/
    • 3.1.0/
      • volcanicAshAdvisory.xsd
  • WAFSSigWxFC/
    • 1.0.0/
      • WAFSSigWxFC.xsd

[amilan17]

• http://schemas.wmo.int/iwxxm/2021-2/iwxxm.xsd

• http://schemas.wmo.int/iwxxm/airmet/3.1.0/airmet.xsd

• http://schemas.wmo.int/iwxxm/common/3.1.0/common.xsd

• http://schemas.wmo.int/iwxxm/gmliwxxm/3.2.1.2/gmliwxxm.xsd

• http://schemas.wmo.int/iwxxm/iwxxm-collect/1.2/iwxxm-collect.xsd

• http://schemas.wmo.int/iwxxm/measures/3.0.0/measures.xsd

• http://schemas.wmo.int/iwxxm/metarSpeci/3.1.0/metarSpeci.xsd

• http://schemas.wmo.int/iwxxm/metFeature/1.0.0/metFeature.xsd

• http://schemas.wmo.int/iwxxm/sigmet/4.0.0/sigmet.xsd

• http://schemas.wmo.int/iwxxm/spaceWxAdvisory/3.0.1/spaceWxAdvisory.xsd

• http://schemas.wmo.int/iwxxm/taf/3.0.1/taf.xsd

• http://schemas.wmo.int/iwxxm/tropicalCycloneAdvisory/3.1.0/tropicalCycloneAdvisory.xsd

• http://schemas.wmo.int/iwxxm/volcanicAshAdvisory/3.1.0/volcanicAshAdvisory.xsd

• http://schemas.wmo.int/iwxxm/WAFSSigWxFC/1.0.0/WAFSSigWxFC.xsd

[blchoy]

One thing: gmliwxxm.xsd is a GML profile (i.e. contains only a subset of the full GML schema to reduce download size). It does not have a version number and should be placed together with iwxxm.xsd.

Another thing: The default location of the XSDs are in the same directory as iwxxm.xsd. I wonder if we can successfully ask EA to create all the subdirectories and create the proper import paths for them in iwxxm.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<schema elementFormDefault="qualified" targetNamespace="http://icao.int/iwxxm/2021-2" version="2021-2RC1" xmlns:iwxxm="http://icao.int/iwxxm/2021-2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns="http://www.w3.org/2001/XMLSchema">
	<include schemaLocation="measures.xsd"></include>
	<include schemaLocation="common.xsd"></include>
	<include schemaLocation="metFeature.xsd"></include>
	<include schemaLocation="WAFSSigWxFC.xsd"></include>
	<include schemaLocation="spaceWxAdvisory.xsd"></include>
	<include schemaLocation="volcanicAshAdvisory.xsd"></include>
	<include schemaLocation="tropicalCycloneAdvisory.xsd"></include>
	<include schemaLocation="airmet.xsd"></include>
	<include schemaLocation="sigmet.xsd"></include>
	<include schemaLocation="taf.xsd"></include>
	<include schemaLocation="metarSpeci.xsd"></include>
	<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"></import>
	<annotation>
		<documentation>The ICAO Meteorological Information Exchange Model (IWXXM) package, including METAR, SPECI, TAF, and other reports as defined in ICAO Annex 3.  IWXXM reports are essential operational meteorology products used to enable safe and efficient air travel worldwide.

The report types in this package include METAR, SPECI, TAF, SIGMET, AIRMET, Volcanic Ash Advisory (VAA), Tropical Cyclone Advisory (TCA), and Space Weather Advisory.

This package builds upon the ISO 19100 family (ISO TC211) and WMO standard meteorological modeling constructs. Additionally, the constructs in this application schema refer to a number of aviation constructs such Runway and Airspace from AIXM.  The full relationship of this package with external dependencies are shown in the 'Package Dependencies' diagram.

Not all of the reports types from Annex 3 are currently represented, this may be expanded in a future version.

References to WMO and ICAO Technical Regulations within this XML schema shall have no formal status and are for information purposes only. Where there are differences between the Technical Regulations and the schema, the Technical Regulations shall take precedence.  Technical Regulations may impose requirements that are not described in this schema.</documentation>
		<appinfo>
			<gml:gmlProfileSchema>gmliwxxm.xsd</gml:gmlProfileSchema>
		</appinfo>
	</annotation>
</schema>

Slight update to Anna's suggestion:

• iwxxm/
  • 1.0/
  • ...
  • 3.0.0/
  • 2021-2RC2/
    • examples/
    • html/
    • gmliwxxm.xsd
    • iwxxm.xsd
    • releaseNotes.txt
    • rule/
    • airmet.xsd
    • ... (ditto XSDs of other packages)
  • airmet/
    • 3.1.0/
      • airmet.xsd --(softlink)-> ../../2021-2RC2/airmet.xsd
  • ... (ditto other packages)

[amilan17]

Another thing: The default location of the XSDs are in the same directory as iwxxm.xsd. I wonder if we can successfully ask EA to create all the subdirectories and create the proper import paths for them in iwxxm.xsd

This is why we need to figure out if it's possible to do this before releasing for focal point review. 

Also, I don't think we should have "soft links", instead I think the iwxxm.xsd should include the XSDs directly, for example:

	<include schemaLocation="airmet/3.1.0/airmet.xsd"></include>

[blchoy]

Also, I don't think we should have "soft links", instead I think the iwxxm.xsd should include the XSDs directly, for example:

Let me re-iterate my proposal:

1. We publish XSDs exactly as what we did before; all of them under http://schemas.wmo.int/iwxxm/2021-2. In this way XSD files are categorized according to the IWXXM version number.
2. At the same time, we would also like to categorize the XSD files according to the packages and their version numbers. So we have http://schemas.wmo.int/iwxxm/airmet/3.1.0/airmet.xsd

As the same airmet.xsd occurs in two different places, it is natural to place it in just one place and put its soft link in the other place. But this is not absolutely necessary.

You may want to recall that (1) is essential as the imports requires the specification of paths. (2) is just a way to indicate evolution of individual package, and has no operational significance compared with (1). IMO it is not necessarily be put in a real directory, but can be on a webpage as well.

[blchoy]

As discussed (with @amilan17 and @efucile) a refactored version of IWXXM 2021-2RC2 is made available under branch FT2021-2RC2-r and a PR has also be made for consideration.

[amilan17]

to consider again if this is possible

[blchoy]

@jkorosi studied and discussed his findings at the TT-AvData meeting on 30 Jan 2023. His conclusion is that in order to make sub-packages METAR/SPECI, TAF, SIGMET, etc. invariant across different versions of IWXXM, they will have to have their own namespace. To be more specific, the targetNamespace will have to change to one specific for METAR/SPECI in metarSpeci.xsd of IWXXM 2021-2:

<?xml version="1.0" encoding="UTF-8"?>
<schema elementFormDefault="qualified" targetNamespace="http://icao.int/iwxxm/2021-2" version="3.1.0" xmlns:iwxxm="http://icao.int/iwxxm/2021-2" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns="http://www.w3.org/2001/XMLSchema">
	<include schemaLocation="common.xsd"></include>
	<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"></import>
        ...
</schema>

This effectively raise the metarSpeci.xsd from sub-package to package level, similar to METCE, AIXM and GML. This is going to be a significant change not only to the schema and schematron rules of IWXXM but also the instances.

We are looking forward to views from new team members who will be joining in a couple of month's time.