Issues with IWXXM METAR schema

[mgoberfield]

I found some inconsistencies/repetition issues within metarSpeci.xsd which could be addressed while we're reviewing the entire schemas for IWXXM 3.0. #27

• - is it necessary to have the element name contain "TrendForecast"? Counterexample, this is not done for visibility in the trend forecast. - in the observed section of the schema, it's simply .
• and - could be simply since they are nested inside their respective 'trend' and 'observation' records.
• and - similar issue as previous - requires a gml:id, however does not.

[braeckel]

• The natural way to simplify would be to rename AerodromeSurfaceWindTrendForecast to AerodromeSurfaceWindForecast. However AerodromeSurfaceWindForecast already exists in TAF and cannot be re-used within the iwxxm namespace. As these are distinct types with an existing relationship this may be best to leave as is, the names are appropriately indicative of where they are used. This pattern of obs/fcst/trend fcst is used in several places in the schemas for METAR/TAF constructs and the current incarnation seems broadly consistent with other areas of the schemas
• presentWeather should remain the same because it must remain distinct from recentWeather on the same type, but forecastWeather can be changed. This would be consistent with TAF
• Agreed that these names (AerodromeObservedClouds and AerodromeCloudForecast) are inconsistent, the simplest path is to rename AerodromeObservedClouds to AerodromeCloud. This matches the naming pattern of many other classes in METAR and TAF (METAR/SPECI has no "Observed" portion in the names and TAF ends with "Forecast")
• Also agreed that it is unfortunate that AerodromeCloudForecast requires a gml:id whereas the former AerodromeObservedClouds does not, but this is a necessary difference to represent NSC conditions that are not possible to report in a METAR. In other words, to have a nilReason (which is required for AerodromeCloudForecast for certain cases) it needs to be a Type, which also brings with it a gml:id. Perhaps there is another intermediate solution (in between Type and DataType) for this. For example, a DataType with an extra nilReason, but this approach seems to run into a limitation in the EA generation capabilities that is difficult to work around (Choy: This is a characteristic of GML to XML serialization, not a limitation of EA. See #19 for details)